I've got a mixed c++/c# project. The original project is c++ and has been extended using c# assemblies. In the beginning this was ok, but since the c# part is growing I experience a big problem growing:
Compile time of the c++ part becomes a problem.
Why? Simple: every time I change something in a c# project, the c++ compiler is not sure if this is important (meaning, it is unable to know if I changed part of the interface or only internal implementation) and does recompile the whole c++ project.
This is a becoming a huge problem since I need to use the c++ part to test the c# part, and right now I'll have to wait several minutes for every little code change.
I need to find a way I do not need to recompile the whole c++ program, but only the parts which depend on the c# assembly or nothing, if the interface of the c# assembly was unchanged.
Is there any way to achieve this?
[Update]
I'm using Visual Studio 2010 Premium.
You could extract interfaces from your C# classes and put those interfaces into a separate C# project. Since these interfaces will not change each and every time an implementation (in your original C# project) changes the C++ projects do not need a rebuild.
Related
In my solution we have projects both in c#, that controls some GUI and networking work, and c++, that manages some hardware interactions. In my c# project I have the proper PInvokes and am able to use the c++ output dll with no issue but in order to do it, I have to manually copy the output dll to the build directory or create a build script that manages the copy.
My issue with this method is that the solution, in reality, has many many projects, something like 150 at the moment, covering c++, c, c#, and vb.net. We create and delete projects all the time and managing the copy scripts is becoming a major pain. Especially since not all of the projects rely on each other and we have like 20 different build configurations.
Is it possible to simply have the c# project reference the c++ project and automatically copy the project output the same way it does with other managed projects without using post build scripts?
Well, the way I do it and have always done it is by obviously using Visual Studio, and assuming this C++ projects are VS projects you can easily create a VS Solution containing multiple projects that you can organize with "Solution Folders". The organization of your projects inside the solution is really up to how you want to organize it. It resembles a file system with nested folders. Needless to say that you can host projects in different languages such as C++, C#, VB...I'm not too sure if you can include a C project or not, that's out of my expertise.
See a screenshot below of a solution I created to demonstrate this...
Notice that "Business" has a nested solution folder (Utils) which contains a C++ project (ERM.CPPLibraries) and a VB project (ERM.VBLibraries). Then if you reference projects within the solution (Right click -> Add Reference), you will not need to copy the output assemblies everytime you compile your solution (or project(s)) VS is smart enough to resolve all dependencies, resolve them and update them.
Hope it gives you an idea
Edit based on comment
In simple words...No, it's not possible to reference a unmanaged project from a managed project in a VS solution. You can reference DLLs but not projects itself
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.
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 have an F# application that references a C# assembly (in this case as a project in the same solution) in order to use an existing C# code base. The problem is that every now and then, the F# project seems to go fubar and not recognize the referenced C# assembly, giving me a "The namespace or module 'HCGInterfaces' is not defined". The C# Assembly compiles just fine. I have rebuilt/cleaned the solution, deleted the dlls, removed and re-added the reference and nothing seems to work. The only way that I can get the application up and running again is to delete the F# project and re-add all the F# files. Any idea why this happens and how to stop it from happening? Rebuilding a project from scratch each time is not a really fun option.
Thanks for your help!
[Update] I was able to get my project working again (although I don't know how or why), but now it won't recognize another C# library that I have referenced. In this case, it will not recognize any classes in it, only the interfaces that are part of the library. Very strange. I haven't been able to find anything about this issue, but I'm getting really frustrated with F# (or at least Visual Studio) at this moment!
In C++, you can create usable code modules by creating a class, and giving out header and implementation files to the developers who want to use your class.
I want to do this in C# but I have little experience with the C# language. Basically I need to create a class that can be reused by another C# programmer in Visual Studio 2010. I know that referencing DLLs is one way to use other peoples' classes. Do I need to create a DLL to achieve what I want to accomplish? Or are there other, better ways?
For example, let's say I create a Cow class that can "moo". In C++, someone who uses my class would just include Cow.h, instantiate a Cow object myCow, and then call myCow.moo(). How can I achieve this simple task in C#?
Thanks for your time and patience.
Yes, just create Class Library project and share the resulted dll's.
Other developers will just need to add a reference to your dll and after that they're free to use any public objects from your library.
It is the standard to create a dll to distribute reusable code.
You could look into old school COM objects, but I would steer clear of them and just use a well organized class library.
Of course you can always share your source files, but the recommended .Net way of distributing reusable code is though dlls. This allows developers using any .Net language to use your code (they don't have to use the same language as your project).
It also makes it easier to maintain the project. If you share source code then it will likely be more difficult to distribute updates than if you just needed to update a single dll. If you have multiple projects referencing the same dll, they can all reference it from the same location and whenever the dll is updated, all the projects that use it will automatically use the updated dll the next time they compile the project. You can also update the dll without having to recompile the projects that use it (though you can't change the names/signatures of anything that is being used by the project).