I'm trying to disassemble some of the DLL of the new WPF4 Beta2 framework. However, all I have is empty methods for all types. I'm not having this problem for other DLL (for example mscorlib).
Do you have any idea what is causing this behavior ? Is this anything to do with type forwarding (I know that some WPF types have moved in System.Xaml.dll).
Actually I found the problem (however I don't really understand it...), I was not using the right DLL.
I was using DLL in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0 whereas I should use C:\Windows\Microsoft.NET\Framework\v4.0.21006\WPF
I personally am not sure, but Red-Gate does have a group they watch for Reflector:http://www.red-gate.com/messageboard/viewforum.php?f=85 you might try posting there if you don't hear anything back soon.
I would imagine that the problem is the fact that this relies on some of the new features of .NET 4.0. Support for these has just been added to the latest early access build of Reflector, which you can download from here:
http://www.red-gate.com/messageboard/viewtopic.php?t=10835
Related
I've got this error that I just can't figure out.
I'm using VS 2012 (VS11) on Windows 8 with .net4.5 and I get this error when compiling a project that worked with VS 2010 and .net4.0.
This is the full error:
The type System.Windows.Input.ICommand exists in both 'c:\Program
Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\PresentationCore.dll'
and 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.dll'
If anybody could provide some insight on what is causing it and/or how to fix it I'd be grateful.
Thanks.
c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.dll
The message is accurate, ICommand indeed exists in both assemblies for .NET 4.5. The problem is your reference to System.dll, your project is using the wrong one. The assemblies in the Microsoft.NET directory are no longer suitable to act as reference assemblies, like they were in versions of .NET prior to .NET 4.0. They should no longer be there but unfortunately are required to get C++/CLI projects built.
Your reference to PresentationCore.dll is correct, it uses the c:\program files\reference assembly subdirectory. The proper home for reference assemblies in .NET 4.0 and up. These assemblies are special, they contain only metadata and are not a copy of the runtime assemblies.
You'll need to fix your project. System.dll is probably not the only assembly that has this problem. Open the References node of your project and verify them one by one. Remove bad ones that point to Microsoft.NET and replace them with good ones by using Project + Add Reference. Best to just replace them all to be sure.
I had a similar problem with fxcopcmd V12.
I was able to solve it by explicitly adding
/reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\WindowsBase.dll"
See: FxCop engine exception on WPF assembly
Take a look at this similar post, How can I resolve this? The unit type exists in two dll files, it suggests that you are referencing two assemblies with the same type, so you would need to give the type you want to use the fully quantified name.
We had the same problem with our libraries after moving to a new build server.
The solution was to specify the path of the .net framework to build against:
/p:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
If the .net 4.0 framework (Multi-Targeting Pack) is not installed on the build server (as it was with us), you can just copy the "v4.0" folder with all its assemblies to the build server ;)
Has anyone tried using Confuser to obfuscate Silverlight projects, or know if it is possible to do so?
I tried using it on a dll from a xap, however it ended at a user-defined breakpoint and then gave the following message:
System.NotSupportedException
Message : Version not supported: 5.0.5.0
[Using Silverlight 5 (v 5.0.61118.0)]
Thanks
Confuser does not support Silverlight at the time of writing. The feature has been proposed, and marked as active on the project's issue tracker.
It's open-source software and possibly it would work on Silverlight if the code is altered to detect the Silverlight libraries. There might be issues with XAML renaming, and there would be an issue with datacontexts being set since that uses reflection, but those could be avoided by turning off renaming and using a different obfuscator to that part.
I have a C++/CLI library that I would like to use in a Silverlight application. It is supposed to be possible to write code for Silverlight in any .NET language, but so far I've only worked out how to compile C#. Silverlight does not seem to be able to use DLLs compiled for .NET.
I'm using Visual Studio 2010 and Silverlight 4. The only new projects available for Silverlight are C# projects. Porting the code to C# is not a practical option.
How do I compile C++/CLI code for Silverlight?
I think I may have gotten a VS2010 C++/CLI class library project to build with references to (only) Silverlight assemblies.
Update
Ok, it is possible. But it is not nice.
First, you must convince the C++ compiler to NOT load the .NET Framework, using an undocumented compiler switch. But that's not the worst part.
Set your C++/CLI project "Common Language Runtime Support" to /clr:safe
Next, under References, remove all references.
Next, in the C++/CLI project properties, under C++ > Command Line, enter /d1clr:nomscorlib /FU"C:\Program Files (x86)\Microsoft Silverlight\4.0.50917.0\mscorlib.dll"
Now, save the project and exit Visual Studio. Open the .vcxproj in a text editor, and change the framework version setting. You want it to be the same as a C# Silverlight project:
<TargetFrameworkIdentifier>Silverlight</TargetFrameworkIdentifier>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<SilverlightVersion>$(TargetFrameworkVersion)</SilverlightVersion>
Now, reopen Visual Studio, and build the project. You'll get an error because the compiler auto-generated a file with #using<mscorlib> and the search path finds the .NET Framework version first.
Silverlight,Version=v4.0.AssemblyAttributes.cpp(1): fatal error C1197: cannot reference 'c:\windows\microsoft.net\framework\v4.0.30319\mscorlib.dll' as the program has already referenced 'c:\program files (x86)\microsoft silverlight\4.0.50917.0\mscorlib.dll'
Double-click the error to open the auto-generated file. Replace the path-less reference with e.g. (here's where you put your references, not in the project properties)
#using <c:\program files (x86)\microsoft silverlight\4.0.50917.0\mscorlib.dll>
#using <c:\program files (x86)\microsoft silverlight\4.0.50917.0\System.dll>
#using <c:\program files (x86)\microsoft silverlight\4.0.50917.0\System.Core.dll>
Luckily, the compiler leaves your changes in-place. So you should be good as long as no one cleans your temp directory.
Building should now succeed.
Then, you need to go add the DLL created by the C++/CLI project to your Silverlight application. Note that you can't set up a project reference, because VS2010 still isn't convinced that the C++/CLI is a Silverlight project. So you'll have to browse and add the reference as an assembly file. (And it won't automatically switch between Debug and Release to match the Silverlight application).
Final Notes
I got it to run an empty Silverlight application in Debug mode and stop at a breakpoint in the middle of C++/CLI code. Also the C++/CLI code successfully returned a value to C# and the local variable in C# received the correct value. So I guess it's working.
I went through a bunch more steps trying to make this work, but I don't think they affected the outcome. If you run into errors, though, let me know and I'll try to figure out what I omitted from this answer.
Ben Voigt, thanks for this, it worked for me too.
Also, if your C++ code does anything that is specific to the C++ language (i.e. not entirely IL portable) like using stack semantics for an array, you'll get the following error:
could not find assembly 'Microsoft.VisualC.dll' etc.
If you recompile with the full .NET Framework and then dump the IL code, you'll find references to "''.$ArrayType$$$BY06$$CB_W modopt" or something similar. This tells you where to change the code.
I found that after I installed the Silverlight SDK and it got added to "\Program Files(x86)\Reference Assemblies" I did not have to go through all of Ben Voigt's steps, just changing the project file was enough.
Another note, you can also use:
<TargetFrameworkProfile>WindowsPhone71</TargetFrameworkProfile>
if you want to target Windows Phone (install the SDK first).
Silverlight does not support native C++ libraries, nor any P/Invoke scenarios due to security concerns. If your library is pure .Net you might be able to decompile it with ILDASM and recompile for Silverlight with ILASM.
Silverlight is not a powerful development platform like .NET which is tightly integrated with operating system. First of all silverlight is supposed to run on any operating system, so there is no choice of Native API anywhere in silverlight.
Silverlight also does not support MSIL completely, so there is lot of problem in compiling and recomiping it at IL level.
Can you say more about what kind of C++/CLI code you have? Most Rich internet applications (Silverlight's target) do not include any of high powerful computation, instead they are plain simple HTML+JS alternatives. For powerful graphics, you can use Silverlight's PixelShadder support.
Reflector
What you can do alternatively is,
Compile your C++/CLI to regular .NET DLL, use Reflector to disassemble and generate C# source code from your dll, it may not be perfect, but you will have most of your logic converted back in C#.
I was able Ben Voigt's solution to work with some minor changes in Visual Studio 2013
Here is what I did different.
Unload the silverlight project that you want to reference it in. Right click and choose edit project.csproj
Copy the Target Framework Settings. For me this was
<TargetFrameworkIdentifier>Silverlight</TargetFrameworkIdentifier>
<TargetFrameworkVersion>v5.0</TargetFrameworkVersion>
<SilverlightVersion>$(TargetFrameworkVersion)</SilverlightVersion>
For the compiler switch /d1clr:nomscorlib This was not working for me. Also a reference to mscorlib for silverlight was automatically added to the complied output without specifying it on the command line options. This is how I got around it.
Open the project in Just Deompile
Load the Assembly Editor Plugin
Navigate the tree to the references
Delete the reference to the non silverlight mscorlib from the reflexil menu.
Right click on the top level of the tree for the assembly, and save as under the reflexil menu.
I haven't tested all of the functions, but the ones I have tested so far worked as expected.
Thank you Ben, your post has saved me a lot of time. I was thinking I was going to have to port my library:)
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
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.*