In Visual Studio when I "build" my project, does that mean that I "compiled" the source code to machine code?
If so, why not call it "Compile"?
As said by #pm100, Building does many things apart from compiling, the compiler at first compiles the code from C# to byte code (not to machine language in C# case). Here you get multiple pieces of compiled code, these pieces are not related to each other.
Here comes the role of linker, it links the multiple pieces (they are also called objects). Now the files knows how communicate and use the code from each other.
Now Visual Studio may do something else, like calling post-build hooks, copy the files to the output directory, etc.
Related
I want to obfuscate a single .dll file (to hide constants). When I confuse .dll compiled as release for any processor AND application is started from .exe - everything works fine.
Unfortunately this .dll is meant to be a "key" for some things in our database that we want to give to someone else to use. But I don't want them to be able to recover this source code in like 2-3 clicks by DotPeek or any other reverse engineering tool for C#. They are still testing their things, so they start their app from Visual Studio.
When I add non-obfuscated .dll to my test project as reference - everything is fine. But when I add already obfuscated .dll as reference I get 'FatalExecutionEngineError'. And that's unfortunately the whole point - I want them to have this .dll for usage and testing purposes, but after obfuscation it may not be possible for them to use it from Visual Studio.
Am I doing something wrong or should I just use a different obfuscation tool?
I'm trying to develop an Application in .Net4, that creates a custom Window, inserts custom controls and saves it in a directory. My next challenge is how I can generate/build additional code from my Visual Studio Solution in a WPF .exe Aplication. I need only some classes that will be generated and transformed to a .exe. This classes will give the logic to navigate from one Window to another.
Here is a little diagram that I did for the question:
Things that I have researched:
CSharpCodeProvider: I can pass some classes in a string[] but I don't know how they will work with dependency, or when a error/bug occurs it will be difficult to see where the error is. And finally worst thing is that I can't set a location to build this .exe. It's built in the main Solution/Bin/Debug.
MSBuild: Here I can set the location where I will build the solution, but for this I need an extra Visual Studio Solution. What I'm trying to do is to have inside my Application a Build button that can build like in Visual Studio a .exe program but with custom classes that I will have in my Application.
I don't know if its possible, I was looking for it but I'm a little bit lost. I see in http://www.icsharpcode.net/opensource/sd/ that the have a builder, and they can set the location and build a .exe from the code. The only difference from SharpDevelop is that my controls and Window are customs.
UPDATE:
Maybe what I'm trying to do is better with other tools. Maybe compiling C# in runtime is not he best way. I will appreciate another ways to solve the problem.
What I do is Creating a new extra project for this .exe and must just copy/paste this .exe to each Project location.
But this is not very useful, if every time we must copy/paste this .exe
I just searching or a solution. I made this as a alternative solution but I don't like it so I will continue to investigate for a generation tool or something else.
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.
I think I know what a build is. But I am not sure. My definition of a build is another word for saying compiled application. Can someone please tell me what exactly a build is. And why do people ask for 3 types of builds. Such as Debug Build, Profile Build and a Release Build. What are the differences.
[edit]
the types of builds
Have a look at Visual Studio Debug and Release Modes
Release Mode
When an assembly is built in release mode, the compiler performs all available optimisations to ensure that the outputted executables and libraries execute as efficiently as possible. This mode should be used for completed and tested software that is to be released to end-users. The drawback of release mode is that whilst the generated code is usually faster and smaller, it is not accessible to debugging tools.
Debug Mode
Debug mode is used whilst developing software. When an assembly is compiled in debug mode, additional symbolic information is embedded and the code is not optimised. This means that the output of the compiler is generally larger, slower and less efficient. However, a debugger can be attached to the running program to allow the code to be stepped through whilst monitoring the values of internal variables.
A build means basically doing a set of tasks to make your program. The main components of a typical build is compiling and linking.
More specifically a build can contain compiling, linking, setting version numbers, copying outputs to some location, creating an installer and anything else.
When people say debug or release build or etc., they may have different settings defined for each. For example in a debug build you will create program database files for debugging.
A build does not have to include only compiled and linked targets. Usually there is at least one of those, but a "build" could also include creating plain-text or binary files, moving images, sounds, and other files into the correct places to be accessed by the file, or any other operation that needs to be performed for the application to run.
The multiple types of builds are made to target different "audiences", if you will. For instance, and end-user does not need to collect information about what functions were called or how many times and exception was raised, or any other diagnostic info (though that information is valuable to developers). Usually the final "release" build is made to be fast and small, and not load the user down with extras like that.
I have a C# project that I need to change its product name upon compiling. I used the prebuild event to change it in the AssemblyInfo.cs but a few times Visual Studio doesn't get this change and compiles it with the previous product name. So i prefer to change it after compiling from another executable (all in C#).
Once the assembly is compiled, you can't (or at least shouldn't) change that information. It's compiled into a resource file inside the assembly that's not designed to be changed.
Visual Studio should always pull that information in, because it's part of the code. If it's not, that may be a sign of a bigger problem, because Visual Studio is not compiling the code you expect to be compiled, and there may be rogue versions of other code files being included as well. Try doing a complete Rebuild Solution, and make sure that the product name is then correct; if not, move the code to a different machine and compile it there, just to make sure it's not pulling in files from somewhere else on your machine for some reason.