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.
Related
According to http://blogs.msdn.com/b/junfeng/archive/2005/02/12/371683.aspx I should be able to create a single .exe file build from some source code and a .netmodule file. However, after looking at http://msdn.microsoft.com/en-us/library/92b5ab4h.aspx and http://msdn.microsoft.com/en-us/library/k669k83h.aspx I cannot seem to make this happen. Whenever I run my .exe it is looking for the .netmodule externally.
Does anyone know of any example showing which options I have to pass to csc to make this do what I want?
For example I have, common.netmodule and program.cs, and I want a single file program.exe that has common.netmodule in the assembly.
After rethinking things, I decided to solve the problem at the source code level. Instead of compiling a common.netmodule file, I just have Maven copy my common.cs file into the project specific directories, and then compile. It works, it's simple, and I cannot believe I wasted so much time trying to figure out the abstruse details of .Net assemblies.
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.
Can anyone tell clearly about the usage of header files and namespaces in C#?
Because in C++ I was using ******.h files to read library functions. And when I saw some sample programs in C# they were missing, Can anyone tell me why?
I'm using C# to develop a custom tool for a CAD application. Whenever I use the appropriate function to open the file (CAD file), the compiler is giving me an error stating that the function names which I supply are not available in the context. Here what does meant by context?
When I opened the help file of that CAD application the function which is responsible for opening the file has bee mentioned under a header file called uf_part.h. But there is an namespace called NXOpen.
I used the namespace as using NXOpen in Visual Basic, isn't that enough? DO I need to supply that header file as well? If so, how?
C# is more "programmer friendly". When dealing with files of the same project, instead of manually specifying "header file" every time, it will go and look in all the project files for a match according to the namespace.
To understand this, do the following steps:
Start new project in Visual Studio. (No matter what type, WinForms or Console)
Right click the project and add new class.
In your main class note you can see the new class you just added, without adding any header.
How this is done? Simply by having the same namespace to both classes. The .NET engine is smart enough to link all those classes together.
Now, when it comes to external code meaning code sitting in a different DLL file the trick is to add reference to that DLL (in Studio --> Right click project --> Add reference --> Browse) then you need to specify you are going to use that DLL by adding a using statement on top:
using ExternalDllName.ExternalNamespace;
That's about it. Unlike C++ you don't need to have .h file as .NET will automatically search the referenced DLL files for a match.
There's no such thing as header file in .net, because all needed metadata is contained in referenced assembly itself.
Have you referenced needed assembly in you project?
Also please mind that there's no such thing as "function" in C#, only class methods (which means that you have to specify object or static class in you call).
Also: General Structure of a C# Program
Compilers for modern languages, such as C# or Java store within compiled files information on the classes and methods they contain, and this information can be used to check the correctness of calls made from one source file to another or to library classes.
When C was invented disk space, memory and CPU power were precious resources and this approach would not have been possible. Header files were introduced to allow the compiler to check that different source files conformed to the same interface. When C++ was invented the approach described above could have been possible, but I guess that it was chosen to stick to the C one for compatibility reasons.
I got many .dll files for my project.
It is quite troublesome that moving a lot of .dll around for a project.
Is there any simple method to group many .dll file into one?
I heard something call dll wrapper but I cannot find out any concrete method related to it.
Can anyone give me a hand please.
Thank you very much.
By the way, all my .dll files and project are written in C#.
You can use ILMerge utility
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly.
It is quite troublesome that moving a lot of .dll around for a project.
Really? Define many. I have projects consolidating 50ü+ dll#s and you know what - it is trivial to move them. Scripts, installers all do that automatically. Including configuring a dozen build server agents with the necessary copies etc.
Really, the only time I have to copy thm around is when I deploy manually to another machine for hotfixing or manual testing. I do that quite a lot at the moment (develop local, copy / paste the folder content to another machine to run tests - faster and closer to the database). Trivial. if it gets more work, I put in a little script. Trivial again.
Being a programmer is not about just knowing how to write some small classes, it also involves optimizting your environment a little. In times of CI (Continuous integration) and pretty much mandatory installers knowing more than just your programming langauge is a must. And then this is trivial.
You could unite your DLLs into a single multi-module assembly, or just create one giant C# project that includes all the DLL source files and compiles everything into a single DLL.
However, what's the problem with moving several DLLs around?
I've got a bunch of .dll assemblies, such as HtmlAgilityPack and MoreLinq. Where am I supposed to put these files? I usually toss them somewhere in my Projects folder, but then I'm always digging around for them. Is there a standard place to put them?
There's no standard place to put them, but make sure you:
Put them in one place
Include them in source control.
I put all my required dll's in a top level directory in my solution called "Dependencies", parallel to the project folders. I have them in source control such that when new developers check out the solution, it all compiles and works right off. It's the only way to go.
I include only the .dll files absolutely needed. This keeps it light, which is good, but then when I find some other part of MVC Contrib or whatever that I need, I have to go find the unzipped directory, which might not even be on my computer! Others put entire library directories (readme.txt and all) as part of their source control linked to the solution. This ensures you and future developers will have everything they need, but adds a little dead weight. Either is a good strategy.
Having a "Lib" folder at the same level as source projects is a common way.
To be honest, it's not the dependencies my projects have that I find hard to manage, it's the dependencies the dependencies have. I'd just like to mention NHibernate, Castle Windsor and the various Castle Windsor Facilities in particular. Getting all of those to play together on my last project cost me a lot of time.
For open source projects, I also like to have the source code handy because sometimes its useful to debug into the source code. (And sometimes because the documentation is so poor, you have to read the source code to find out how it works). I've seen VS projects arranged so that the project references the DLL yet at the same time, VS knows where to find the source code, as I write I can't quite remember how to do that.
So, a Lib folder for DLLs works for me; I often call it "Shared Dependencies".
As for open-source source code, I don't have a standard way to version that because each project is structured differently and has a different build process. I don't like to tinker with the open-source project structure or build method because then, I take responsibility for it. If for some reason, it won't build, or builds incorrectly, or produces a faulty DLL, the cause would be exceedingly difficult to track down, and I'd have to get deep into troubleshooting all of that which I dont care about at all.
In a folder UNDER your solution directory, e.g. "external" or "library". That way your continuous integration system (or other team members) can do a pull of one root from your source control system and have everything they need.
In SVN, use svn:externals to pull that directory from a different root so you can easily share library DLLS (and library projects) between solutions.
In the office we have a share on the network for referenced asseblies. These could be 3rd party or assemblies of our own that could be shared between projects.
I also, don't like the idea of putting the dll files in source control. If all the developers have access to the share all will work fine.
The visual studio directory in My Documents seems like a logical place to put them. I don't know if it's the best or anything wrong with it but at least all the libraries are found in one place.
%USERPROFILE%\My Documents\Visual Studio XXXX\Libraries
At my company we place all our shared DLL assemblies onto a network drive in a folder called Assemblies. From there, we use SyncToy to mirror changes between that folder and a folder on our local development machines (in my case C:\Assemblies with subfolders for different versions or useful third party assemblies). Using the "Reference Paths" feature of Visual Studio projects makes it very easy to select different assembly versions based only on locations.
For projects at home, I would definitely go with the idea mentioned by Jeff M of placing them in the Visual Studio folder under My Documents.
I don't have a hard and fast rule on the location. However, I would encourage consistency!
For example, I needed to to this for a small tool I'm writing for a client at the moment, so I checked their other code bases in Bitbucket which seemed to use a dependencies folder in the solution folder (alongside the other projects), so I copied that.