I'm wondering if i can change a function in system.dll
like instead of return 0; i change it to return -1;
and recompile it and use it again.
If yes how we can do it ?
No, you can't. You can't because you can't strongly sign the assembly you would produce with the Microsoft signature, and so all the other assemblies that reference the System assembly would complain (I know this because two weeks ago I tried to do something similar :-), but I didn't want to recompile. For me it was enough to use Mono.Cecil to directly edit a copy of the System assembly)
If you are writing unit tests, you could use Fakes (requires Visual Studio Premium). It let you redirect methods of an assembly to your code, controlling the output and what the method does.
Technically you could do what the Fakes "library" does with this: http://www.codeproject.com/Articles/453065/ILRewriting-for-beginners But note that it is complex. You create a "runner" for your exe in C/C++. This "runner" (it is technically a CLR Host) can rewrite "on the fly" the .NET code of an assembly.
Related
Since version 3.0, .NET installs a bunch of different 'reference assemblies' under C:\Program Files\Reference Assemblies\Microsoft...., to support different profiles (say .NET 3.5 client profile, Silverlight profile). Each of these is a proper .NET assembly that contains only metadata - no IL code - and each assembly is marked with the ReferenceAssemblyAttribute. The metadata is restricted to those types and member available under the applicable profile - that's how intellisense shows a restricted set of types and members. The reference assemblies are not used at runtime.
I learnt a bit about it from this blog post.
I'd like to create and use such a reference assembly for my library.
How do I create a metadata-only assembly - is there some compiler flag or ildasm post-processor?
Are there attributes that control which types are exported to different 'profiles'?
How does the reference assembly resolution at runtime - if I had the reference assembly present in my application directory instead of the 'real' assembly, and not in the GAC at all, would probing continue and my AssemblyResolve event fire so that I can supply the actual assembly at runtime?
Any ideas or pointers to where I could learn more about this would be greatly appreciated.
Update: Looking around a bit, I see the .NET 3.0 'reference assemblies' do seem to have some code, and the Reference Assembly attribute was only added in .NET 4.0. So the behaviour might have changed a bit with the new runtime.
Why? For my Excel-DNA ( http://exceldna.codeplex.com ) add-in library, I create single-file .xll add-in by packing the referenced assemblies into the .xll file as resources. The packed assemblies include the user's add-in code, as well as the Excel-DNA managed library (which might be referenced by the user's assembly).
It sounds rather complicated, but works wonderfully well most of the time - the add-in is a single small file, so no installation of distribution issues. I run into (not unexpected) problems because of different versions - if there is an old version of the Excel-DNA managed library as a file, the runtime will load that instead of the packed one (I never get a chance to interfere with the loading).
I hope to make a reference assembly for my Excel-DNA managed part that users can point to when compiling their add-ins. But if they mistakenly have a version of this assembly at runtime, the runtime should fail to load it, and give me a chance to load the real assembly from resources.
To create a reference assembly, you would add this line to your AssemblyInfo.cs file:
[assembly: ReferenceAssembly]
To load others, you can reference them as usual from your VisualStudio project references, or dynamically at runtime using:
Assembly.ReflectionOnlyLoad()
or
Assembly.ReflectionOnlyLoadFrom()
If you have added a reference to a metadata/reference assembly using VisualStudio, then intellisense and building your project will work just fine, however if you try to execute your application against one, you will get an error:
System.BadImageFormatException: Cannot load a reference assembly for execution.
So the expectation is that at runtime you would substitute in a real assembly that has the same metadata signature.
If you have loaded an assembly dynamically with Assembly.ReflectionOnlyLoad() then you can only do all the reflection operations against it (read the types, methods, properties, attributes, etc, but can not dynamically invoke any of them).
I am curious as to what your use case is for creating a metadata-only assembly. I've never had to do that before, and would love to know if you have found some interesting use for them...
If you are still interested in this possibility, I've made a fork of the il-repack project based on Mono.Cecil which accepts a "/meta" command line argument to generate a metadata only assembly for the public and protected types.
https://github.com/KarimLUCCIN/il-repack/tree/xna
(I tried it on the full XNA Framework and its working afaik ...)
Yes, this is new for .NET 4.0. I'm fairly sure this was done to avoid the nasty versioning problems in the .NET 2.0 service packs. Best example is the WaitHandle.WaitOne(int) overload, added and documented in SP2. A popular overload because it avoids having to guess at the proper value for *exitContext" in the WaitOne(int, bool) overload. Problem is, the program bombs when it is run on a version of 2.0 that's older than SP2. Not a happy diagnostic either. Isolating the reference assemblies ensures that this can't happen again.
I think those reference assemblies were created by starting from a copy of the compiled assemblies (like it was done in previous versions) and running them through a tool that strips the IL from the assembly. That tool is however not available to us, nothing in the bin/netfx 4.0 tools Windows 7.1 SDK subdirectory that could do this. Not exactly a tool that gets used often so it is probably not production quality :)
You might have luck with the Cecil Library (from Mono); I think the implementation allows ILMerge functionality, it might just as well write metadata only assemblies.
I have scanned the code base (documentation is sparse), but haven't found any obvious clues yet...
YYMV
I'm trying to change a method in a compiled C#-asp.Net web application. is it possible to somehow override a method inside a compiled dll ?!
I did reflect the dll, but it has tons of references and has been referenced tons of times, so I do not think, even if it is possible because of the hundreds of errors in Visual Studio, recompile the dll would be a good soloution.
Basically what I need to do is to change a FormatDateTime method inside a core dll to add support for an unsupported calendar (date format).
and of course I have access to the server of the application, and I can do what ever I want in Administrator level.
can someone guide me in a direction ?!
You can override the method only if it is virtual, and it doesn't matter whether you do it through reflection or statically.
It think that the best thing you can do is use a decompiler and fixe the code in MSIL. Then you can generate a new assembly from the MSIL.
For a decompiler, you can use the Telerik JustDecompile is simply awesome: http://www.telerik.com/products/decompiler.aspxI
This is a learning for me.
Compile to What Output type or How to Compile a C# Class Library to an Intermediate File, but Not DLL; which can be used in other project without having source code and not passing it to End User.
This is achievable in Delphi/C/C++ as per my knowledge.
which can be used in other project without having source code and not passing it to End User.
It sounds to me like you should compile it to a dll, but perhaps consider ILMerge as part of your build/deploy strategy. And frankly there is rarely any good reason not to simply ship the dll without merging.
Note that csc does allow you to output raw modules, via /target:module (presumably then re-combining with /addmodule) - but frankly that will be a real pain to work with.
Is there a way to keep any DLLs needed for my Visual C# program (such as SQLite) inside the actual EXE so it doesn't require the files to be present?
If not, can anyone show me how to make a wrapper for my program (independent of .NET, so maybe C++?) to copy/load required files to the working directory before starting the program itself.
What I intend to end up with is a single EXE file that can be deployed anywhere and set itself up like a transformer. All it requires is the following criteria:
SQLite is present
OpenHardwareMonitorLib is present
.NET 2.0 is installed (if not, offer install with redistributable package)
Microsoft provide a tool for merging DLLs. It's called ILMerge.
It doesn't always work, I believe certain things can cause problems. But it's definitely the easier option!
If the problem is redistribute only one file, you can create a "installer" exe, that unpack all your dependencies (from executable content).
If you don't want to leave all dlls in your production environment, you can merge all IL code in the main executable. you can use ILMerge (but it's not the only product that can do this)
You can merge the dependencies into the main executable. After your build completes you run an additional tool that combines the IL code into a single assembly.
ILMerge can do this but is a bit cumbersome to use.
Some (proprietary) tools can do this as well. I know of at least one obfuscator (DeepSea) that can do this. DeepSea also allows you to specify what you want to include and what types you want to expose from the resulting assembly.
Full disclosure: I know the guys that build DeepSea Obfuscator.
I guess you could embed the target assemblies as resources and then unpack them in some custom assembly resolution code?
Edit: there's an example of this here: Embedding assemblies inside another assembly
Is there any reason for it is not possible with Visual Studio to remove unused references (to projects and assemblies) in C# and C++ projects while it is possible to do so from a Visual Basic project (see here)?
I know you can do it with other tools like Resharper, I was just wondering if there was any technical reason for not being able to do this in C# and C++ projects? Or did Microsoft just choose it to work like that. It seems to be a quite useful feature.
Note that the compiler will automatically drop any unused references from the assembly, so at the assembly metadata level this is redundant. It then just becomes an IDE/tooling issue. Would it be impossible? no (although obviously it would need to keep any that are marked for copy-local, to ensure it gets deployed). We can probably assume, therefore, that it is simply a "time to implement vs utility" (compared to other more useful things that could be done).
I'm sure you could write an IDE extension for it if you wanted ;p
I found this suggestion on Microsoft Connect. It sounds like Microsoft actually thinks it is a good idea but just did not have the "time" (read: priority) to implement it. Too bad!
This functionality is there for VB (via the "Unused References" button on the References property page).But is the case of CSharp, For example, a user could add a reference to an assembly in order for it to get copied to the output directory. They might be using the assembly via reflection instead of compiling against it -- in such cases, there is no way for VS to detect that such an assembly is "used". So designing such algorithm is not 100% successful. But flag is a option that assembly mark as "unused" (however, the user would still have the choice as to whether to remove the assembly from the list of references).
Remove unused namespaces can do a bit work towards this.