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.
Related
I have a c++/CLI library that is in turn calling a c# library. That is fine, it is linking implicitly and all is good with the world. But for various reasons the libraries are not getting quite the prefect treatment by our automated build process, and the libraries are not finding each other unless we move the libraries to locations that we would rather not have them in, and would rather not fold into our build process.
It is suggested to me that we/I could write a post-build event that uses XCOPY. but lets say we don't want to do that.
Another suggestion is to explicitly load the dll. Windows says that to link explicitly "Applications must make a function call to explicitly load the DLL at run time." The problem is that Microsoft's example is not enough for my small mind to understand how to proceed with this idea. Worse, the only example I could find is out of date. Perhaps I am not using the right search terms but I am having difficulty finding more about it with google.
How do we explicitly Link a c++/Cli Library to a C# .dll?
----edit
OK, How do we explicitly Link a C++/CLI code, which exports a library using __declspec(), to a C# .dll.
There is no such thing as a "C++/CLI library", only assemblies are supported. There is no explicit or implicit linking, binding always happens at runtime. Assemblies are found at runtime by the CLR, the rules it uses to locate them are described in detail in the MSDN library.
Copying all dependencies into the same directory as the EXE is the sane way to go about it while you are developing the code. Well supported by build system, the C# and C++ rules are however different. C++ projects build to the solution's Debug directory, C# projects build to the EXE project's bin\Debug directory. So yes, altering a C++ project's Output Directory setting or copying files with a post build event is usually required to get everything together.
I have an application written in C# (without the source of course), that needs to be changed a little bit. For example, I need to stop a few lines of code that create an unnecessary menu. So I think I should comment them out.
The source code is not obfuscated. I know I can completely decompile, change, and compile again, using tools like Reflector/Reflexil. But everyone knows that by doing this, many parts of code won't compile again! Is there a way in Reflector (or any other product) that a part of could be disabled/changed without this process?
Thanks.
You might want to try dnSpy. It is a .NET assembly editor, decompiler, and debugger forked from ILSpy.
https://github.com/0xd4d/dnSpy
If you really needed to do this, you could decompile it with Reflector (or a similar product) and then use that to try to recreate a solution in .Net that will produce the same executable.
You may run into issues around:
Obfuscated code
Sections where the decompile shows you accurate code for specific sections, but for some reason it just doesn't work in your new solution (and then what do you do?)
This is not to mention the potential legal issues related to doing this. If the executable was released under a license that would permit you to do this, then you would most likely have access to the source code. So the fact that you do not have access to the source code implies that doing what you are suggesting might not be legal.
Eventually I managed to "disable" a few lines of code in the compiled exe.
I used Reflector with Reflexil plugin installed. Reflexil allowed me to edit an MSIL instruction, and then save the result back to an exe file. So, it involved learning a few MSIL instructions, especially the "no operation" command (making a line of code do nothing). To see the list of instructions and a tutorial, see here and here.
Hope it helps someone else.
for the sake of completeness:
Another possible solution is to use the ildasm http://msdn.microsoft.com/en-US/library/f7dy01k1%28v=vs.80%29.aspx
MSIL Disassembler, edit the MSIL and feed it back to ilasm.
How practical this solution is, depends on you of course
This thread may help: dotnet dll decompile and change the code
Last time When I tried with decompile the source using reflection, I got too many compilation issues with regarding to resources and other subs though the dll isn't obfuscated. So there could be things beyond just extracting the source and modifying in order to make your new dll work as the old one.
SO I would suggest to go with direct dll manipulation using any of the options mentioned in the other thread.
If you have source code on the same machine on which you are testing your exe file, and if you are making changes in your sourcecode in visual studio, then while compiling it will automatically get reflected in your exe file.
You need not do any special thing for it. And if it is not, then just make the changes in code and paste your debugg folder's new exe (with debugg folder) on another machine having all recent changes.
I would first like to say my goal is to convert MSIL into native X86 code. I am fine with my assembly's still needing the .net framework installed. NGEN is not what I want as you still need the original assembly's.
I came across ilasm, and what I am wondering is this what I want, will this make pure assembly code?
I have looked at other projects like mono (which does not support some of the key features my app uses) and .net linkers but they simple just make a single EXE with the .net framework which is not what I am looking for.
So far any research has come up with...you can't do it. I am really no sure as to why as the JIT does it when it loads the MSIL assembly. I have my own reasons for wanting this, so I guess my question(s) come down to this.
Is the link I posted helpful in anyway?
Is there anything out there that can turn MSIL into x86 assembly?
There are various third-party code-protection packages available that hide the IL by encrypting it and packing it with a special bootloader that only unpacks it during runtime. This might be an option if you're concerned about disassembly of your code, though most of these third-party packages are also already cracked (somewhat unavoidable, unfortunately.) Simple obfuscation may ultimately be just as effective, assuming this is your underlying goal.
One the major challenges associated with 'pre-jitting' the IL is that you end up including fixed address references in the native code. These in turn will need to be 're-based' when the native code is loaded for execution under the CLR. This means you need more than just the logic that gets compiled; you also need all of the reference context information necessary to rebase the fixed references when the code is loaded. It's a lot more than just caching code.
As with most things, the first question should be why instead of how. I assume you have a specific goal in mind, if you want to generate native code yourself (also, why x86? Why not x64 too?). This is the job of the JIT compiler - to compile an optimized instruction set on a particular platform only when needed, and execute it later.
The best source I can recommend to try and understand how the CLR works and how JIT works is taking a look at SSCLI - an implementation of the CLR based on the ECMA-335 spec.
Have you considered not using C#? Given that the output of the C# compiler is MSIL, it would make sense to develop on a different platform if that is not what you want.
Alternatively it sounds like NGEN does the operation you are wanting, it just doesn't handle putting the entire thing into an executable. You could analyze the resultant NGEN image to determine what needs to be done to accomplish that (note that NGENed images are PE files per the documentation)
Here is a link on NGEN that contains information on where the images are stored: C:\windows\assembly\NativeImages_CLR_Bit for instance C:\windows\assembly\NativeImages_v2.0.50727_86. Note that .NET 3.0 and 3.5 are both part of 2.0.
There are a lot of little things I find myself re-writing here and there because they might be too large/complex to represent as a snippet, but realistically it doesn't make sense to make a stand-alone DLL out of it because we might only be talking a few dozen or a few hundred lines of code.
For example a little form which contains only a text box where the user enters a password and closes on {Enter}.
Or an extension method which can serialise/deserialise any object to/from a GZipped file assuming the object is marked as Serializable.
The list goes on. I have accumulated lots of little bits and pieces over the years and it's not organised in any neat way.
In C++ projects, I can write a lib file containing these bits of code which I can add to my compiler settings in such a way that any future C++ project I create has this lib included. I have done this with ATL and Boost.
I don't know of a way to do this for C# projects. Is it possible?
Edit:
If I make an assembly, I have to compile it to a DLL and distribute the DLL alongside my main executable. The DLL may be small or it may be quite large, I don't know. But I may only need to use a few tiny functions in that DLL for my project. In C++, only the functions I use are statically linked when I use the library, however if I distribute my software with a DLL then I have to distribute everything.
I know it is possible to merge the DLL with the main executable so that the user isn't aware that there is a separate library, however the whole DLL is still being packaged along with the executable.
Imagine I write a DLL with lots of my own maths, stats, file IO, image manipulation, serialisation, user IO, etc included. Nothing fancy, just some common things I find myself doing quite frequently. The DLL might be, say, 4MB.
Now I want to write a program which uses a tiny part of the DLL, and if I were to simply copy/paste the necessary code then my EXE would end up being, say, 700kB.
Are you saying that I either copy/paste the code I need, or I have to distribute a 4MB DLL along with my 700kB EXE?
Aside from using an assembly, the only way I know of is to create a link in your project to the source code in question. In visual studio the process is:
Project → Add → Existing File → Add As Link (the little down arrow:)
It is not possible at a source code level, although often requested (just Google c# #include equivalent). The only reasonable alternative that c# offers is compiling your common code as a DLL and adding a reference to it.
Note that although you can add a file to your project from another project, it will take a copy and therefore not maintain updates. I have used this to achieve the same effect 'manually' - when the common file is updated, I excluded it from the project 'referencing' it and then re-added to get a fresh copy.
UPDATE As commented below, you can add as a link - how cool! Why did nobody tell me.
We add a common directory to the overall includes path, then use
#include <somefile.cpp>
directly in our cpp files. It'll include the source straight in.
so I'm writing a VS2008 C# Add-In to automate AspectC++ weaving in C++ projects. I'm generating the C++ source files (now woven with aspects), but I can't figure out how to compile them as part of the pre-build step. Is there a convenient way to specify new source within the IDTExtensibility2, EnvDTE90, or VslangProj90 namespaces? I've tried using the VCProject and VCProjectEngine interfaces as well as marking the files for inclusion programmatically via the 'ExcludedFromBuild = false' flag. No luck.
I noticed that the commercial AspectC++ Add-In bypasses cl.exe by putting a wrapper around it and the ac++.exe aspect compiler. So they must call their own cl.exe which then calls ac++.exe before preparing the generated source files for the real compiler. That seems like a hack to me, is there not a better way? I'm really stumped on this one, any help would be appreciated.
Why not just include the generated file into the project that you then build?