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?
Related
How do you compile .cs files using C++
I have searched all through Mono's documentation and can't find a way to just compile C# code from the embedded mono runtime in C++. I know how to open a C# .exe assembly file using the embedded mono functions from C++, but I can't seem to find a way to just compile a .cs file to the .exe from C++.
I have also managed to compile the .cs files by calling the mcs.bat file from the CreateProcessA() function that Windows provides, however this does not give me a way to log errors or even check if it succeeded in compilation etc. (It also feels like a hack and not the official solution). The main reason I need to do this is so that I can recompile C# scripts on the fly by detecting when the source code has changed and another subset of conditions.
Does anyone know of a way to properly compile C# files using the embedded Mono runtime? And where to find the documentation for this? Currently I've been using the documentation here: http://docs.go-mono.com/?link=xhtml%3adeploy%2fmono-api-assembly.html which provides enough information for the most part.
Linking Mono in a DLL
Also, if you're familiar with embedding mono, do you know how to use it in a dll? I've managed to successfully link and compile it within a console application, but when I try to compile it as a part of a dynamic library, I get unresolved external symbol errors (specifically functions with the prefix __imp*).
Lastly, I'm using mono to embed C# as a scripting language for my game engine, however I don't know if there is a better (smaller) solution that I can use. If you know of any better solution feel free to leave a recommendation.
The mono runtime is a "Runtime", only for running the code,
but if you have installed the csc command then you can use this:
#include <cstdlib>
int main(){
system("csc yourfile.cs")
return 0;
}
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.
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.
Hi this may be a strange question but I have some c++ code that I would like to compile as c# code using Visual Studio 2012.
The code its self is completely compatible and will compile with both compilers.
What I would like to do is have the c# compiler treat the .c files as .cs files and compile them as c#, the reason for this is I still need this particular c++ file for an old library but dont want to have two copies of the code when I update something.
Currently I have a batch file that copies the .c code from the c++ project within a solution to the c# project within the same solution and it then uses a pre processor and compiles it however I obviously loose breakpoints, etc and it is a bit of a problem.
The file Extension is not relevant just set the Build Action to Compile in the Properties of the file. Syntax Highlighting might have some problems with that but not the compiler.