Is there a way to get the code from a Silverlight publish?
My laptop has completely crashed, and the only thing I have left from my application, is the published website.
Is there a tool or something to get the code from my application?
You can rename the xap to zip, extract it, and use Reflector to pull out the code. It won't recover it exactly or recover the XAML though. As far as I know there's no way to reverse engineer XAML.
Edit: +1 for Shawn for pointing out that the XAML is stored as plaintext resources, so you can recover that too. Not quite sure why it does that, but hey, it's good news :-)
Using .NET Reflector you can can all the XAML. It's stored as resources in plain text.
Try Silverlight Spy. It's a great tool for debugging Silverlight. If you use it in combination with .NET Reflector you can view the decompiled code of any running Silverlight application.
BTW, here are all features of Silverlight Spy.
JetBrains have made DotPeek available. It is currently free (I hope it stays that way, unlike .NET Reflector).
It will also convert Silverlight DLL files all the way back to readable source code! I have tried it on several Silverlight projects, and it works like a charm.
**Note: as of the time of this writing it still gets a couple of things wrong: string concatenations and event handlers generate the wrong code.*
Related
I'm looking for a way to add scripting support with IronPython to an existing .net desktop application and need to be able to have code completion for IronPython there. Code completion should work for keywords, classes, variables, etc. as you type or via Ctrl-Space.
Any suggestions?
Unfortunately, I don't think such a thing exists specifically for IronPython. If you don't need it to be fancy you could something like Scintilla.NET and just run it in normal Python mode and get at least some completion (I think it just suggests things already in the editor buffer).
Providing full IntelliSense is a crazy hard problem, but you could check out the Python Tools for Visual Studio to see how they do it.
Okay, about three to four months ago, while looking for something COMPLETELY different, I was tripping over how-to's on creating Silverlight assemblies. Now that I am actually looking for that info, I can't seem to find it.
Can anyone point me to some resources for taking a UserControl I've created and making an assembly from it?
Thanks!
Create a new Silverlight library in Visual Studio, and add your UserControl to that project.
When you build, it will generate an assembly for you.
Is there any silverlight decompiler available?
Nothing specific to my knowledge, but you can open the xap file (it's just a zip file) and use Reflector to decompile the dlls.
JetBrains have made DotPeek available. It is currently free (hope it stays that way, unlike .Net Reflector).
It will also convert Silverlight DLLs all the way back to readable source code! I have tried it on several SL projects and it works like a charm.
**Note: as of the time of this writing it still gets a couple of things wrong: string concatenations and event handlers generate the wrong code.*
XAPs are just zip files, so you can crack them open and decompile the code using Reflector. Also, it's worth taking a look at Silverlight Spy.
It's all .Net so you can just use Reflector
Given the list of new features announced in Silverlight 4, when is WPF still required?
WPF still has a lot fuller 3D rendering capabilities.
Also even though they announced enhancements to the commanding and binding capabilities, that's no guarantee that it will have the full ability that WPF currently has or will have in the next version
Edit: After playing around with Silverlight 4 beta, it looks like pretty much all of the new features (webcam, file access, full screen keyboard, COM interop, etc) only work when the application is elevated trust, and elevated trust can only be enable when running out of browser. Some of this may change by RTW, but for now, WPF still looks like the only way to do these things inside of a browser window
I've been using mostly XBAPs for browser deployments while waiting for a Silverlight version that includes WPF's full templating and data binding capabilities. Perhaps Silverlight 4 will do it.
Several things that Silverlight 4 definitely won't be able to do are:
Allow you to seamlessly integrate your WinForms and MFC user interface components with your application
Efficiently work with data file structures originally defined in C/C++ (with WPF you can simply copy the code across and easily replicate the original C++ code using unsafe and StructLayoutAttribute)
Include unmanaged C++ code in your application
I have not actually downloaded the Silverlight 4 beta yet, so this list is necessarily incomplete.
The next version of Visual Studio will not be written in Silverlight ;) I can't wait to write an Audio utility in WPF---and Silverlight must be sand-boxed away from the incredible Windows Audio subsystem. However, I can see the day when WPF will be called Silverlight (or perhaps the other way around).
When you don't want to depend on a browser to do your work, when you need full and fast access to the file system without prior confirmation, when doing interop with unsafe bits of code. These are the few I can think of, but they might be other reasons as well, depending on what features Silverlight 4 will really have and how well will they really work.
The applications we (in our company) write today use nothing that is not supported by Silverlight except for local TCP/IP connections without limitations.
This is the only reason we are using WPF.
If we could use Silverlight instead (desktop mode) we'd be able to give our customers
the choice of working on Mac (and linux) systems as well instead of being forced (by us?)
to use a recent version of Windows (you'd be surprised how many companies still use old (partially) unsupported versions).
Even in WPF we try to limit access to the system, we create our own sandbox and
try not to go outside of it. (Never require admin rights, never access stuff you don't have to)
So for what we do, Silverlight + real tcp/ip support would be more than enough...
but there is absolutely still room for WPF and I'm pretty sure it's here to stay.
It all depends on what you're building.
Silverlight will always favor small payloads over functionality. Strategically, Microsoft will attempt to out feature Adobe's offerings using Silverlight, while WPF will be competing against other heavy platforms. If you look at WPF 4 you'll notice a push towards heavier weight features. I try to keep in mind that WPF started out as Avalon which was intended to permanently displace Win32. I won't be surprised if one day Windows XX is "native" WPF and Win32 will be emulated.
If you want to do direct database access through ADO.NET that's not something you'll be able to do in Silverlight 4. Access to devices will still be limited although you will now have some printing support and webcam/microphone. I haven't heard anything about 64 bit support so if you want to offer a 64 bit version of your app you'll need WPF. I also think even if Silverlight 4 makes better use of the GPU, it still won't be to the level that WPF utilizes it.
There are also a ton of other assemblies in the .NET framework that Silverlight doesn't include so if you need any of those you'll need to go WPF.
Just like HTML5 will reduce the need for a plugin like Flash or Silverlight in some cases, Silverlight will reduce the need for WPF but there are still plenty of cases where you'll need it.
WPF is still required if you need to do extensive Rich Text (FlowDocument) editing. Silverlight 4 has the new RichTextBox, but it is limited to very basic content, and doesn't provide the full set of features that are available in FlowDocuments in WPF. A FlowDocument can effectively do what the WinForms RichTextBox can do; but if you only need the basics, a RichTextBox in Silveright may do what you need.
The bottom line is that silver light is limiting. So, if you are going to use a less capable technology you should have a compelling reason for doing so. The only one I can come up with, and it is a big one in some circumstances, is that Silverlight is more platform indifferent. I just can't imagine anyone wanting to bring the browser and all of it's headaches into a solution. There must be a good reason.
I am fairly new with silverlight and I really find it cool. I have a question about how it runs the code client-side tho..
Say for example, I have a site that calculates a certain amount based on user inputted amounts. This of course I would love to do client-side. The catch though, is that the formula used for the calculation is proprietary and a trade secret. If I put this formula client-side using SL, will it be safe? Or can it be reflected?
If you want to keep algorithms secret, don't push it to the client side. No form of obfuscation or protection is ever perfect.
Also, when you have calculations on the client side, you should always check the results on the server, rather than just assuming they're correct. Assume that the client is compromised.
Silverlight pushes the XAP file to the client. The XAP file is simply a zip file containing your .NET assemblies, which can then be unzipped and reflected against. The company I work for (PreEmptive Solutions) markets Dotfuscator, which can obfuscate Silverlight assemblies. Right now you have to unzip the xap, obfuscate and zip them back in, but we're working on improving the workflow.
Just a note to Dotfuscator users: If you create a Dotfuscator project, you must use the "User Defined Assembly Load Path" property in the "Settings" tab to browse to the Silverlight libs. The paths you need are:
\Program Files\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies
\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Client
or on 64 bit operating systems:
\Program Files (x86)\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies
\Program Files (x86)\Microsoft SDKs\Silverlight\v2.0\Libraries\Client
Don't fall into a trap of think hiding the algorithm will protect it. Once you put it on the web somebody will figure it out no matter what you do. With enough sample data anybody with some math skills should be able to figure out your algorithm.
All you can do is make it harder. If this algorithm is is something proprietary that you have bought then it will need to be server side. Putting the algorithm on the client side is essentially publishing it and you could be liable.
IntelliLock and .NET Reactor (my preferred tool) obfuscates my assemblies nicely.
While obfuscation is not a fool-proof method, it makes it that much more difficult for somebody to see your code. One has to really jump though convoluted hoops to get to your final code if the layers of obfuscation are good. Crypto Obfuscator is one obfuscator which supports obfuscation of Silverlight assemblies.
Another cool tool is CodeFort. It has free edition. See it in action at http://www.codefort.org
CodeFort .NET & Silverlight Obfuscator
CodeFort is an advanced obfuscator and protection tool for Microsoft .NET and Silverlight applications.
BAML and XAML obfuscator - obfuscate 100% of your code
CodeFort is the first tool ever to be able to obfuscate identifiers inside the XAML and BAML code which is used in Silverlight and WPF applications. This makes it for the first time possible to obfuscate 100% of your code.
Powerful protection against attackers
Coupling the XAML/BAML obfuscation with powerful protection features such as Reference Scrambling and Anti-Tampering CodeFort is a state-of-the-art obfuscating tool.
I must COMPLETELY agree with Marcus. Even obstruficated .NET assembly is still easy to read for a good programmer.
My solution would be WCF service for the calculation. Just push all the data there and give an answer. If your formula is top secret and not obvious (like ax+by+c*z) then even is somebody would get access to service, then it would be hard for him to get it.
There are many companies that support obfuscating Silverlight 2.0 applications. DeepSea Obfuscator has a nicely integrated experience, Dotfuscator also work and soon, the free Eazfuscator will also support it.