At the moment I have added and referenced another project to my main solution. It works, but then I need the separate dll that is compiled.
How can I reference another project without the need for a separate dll that I have to distribute with my final exe?
A C# class project in a Visual Studio solution always compiles to an assembly, so adding a project reference will inevitably mean that your executable references the assembly built as a result of compiling the other project. If you don't want to distribute the separate assembly with your executable the only thing you can do is to ILMERGE the assembly into your executable as a part of your deployment build process,
You can't. The way .net works is to load an additional assembly and using its meta data the classes inside that. If you are attempting to have a set of classes that you refer to by source similar to the way c++ uses header files you will have to import those files into your project.
This sounds like you're trying to statically compile a library. This is not (easily) offered by .NET without manually creating and merging assemblies.
Related
I have an app that references a .dll that was built with Costura/Fody i.e The dll has all its references embedded. When I run the console app, the references from the dll are not unpacked so the console app throws an exception saying missing .dll etc. as it needs those resources to run.
i.e. AssemblyA.dll embeds MyAssembly.dll when built with Costura/Fody. ConsoleAppC references and embeds AssemblyA.dll but also needs MyAssembly.dll to run. I do have a reference to MyAssembly.dll in ConsoleAppC so that it will compile (but CopyLocal is set to false). I was thinking that MyAssembly.dll would be made available to ConsoleAppC when AssemblyA.dll's embedded resources are unpacked?
This is not working but is my scenario valid in any way or can you only utilise embedded resources from ConsoleAppC and not the ones that were embedded in AssemblyA.dll?
Thanks in advance for any help
Mike
What you're trying to do isn't possible with Costura.Fody. What Costura does is embed libraries directly into the main assembly. This means that if you embed the built assembly into another project, it can't see the sub assemblies.
For example, consider the following project structure:
AssemblyA
Foo.cs
References:
SubAssembly1.dll
SubAssembly2.dll
SubAssembly3.dll
AssemblyB
Assume that Costura.Fody is used to embed the sub assemblies in AssemblyA, creating a single DLL file, AssemblyA.dll
If you embed AssemblyA.dll in AssemblyB, then you will not be able to access classes in SubAssembly1.dll. You will only be able to see any of the classes that are directly in AssemblyA.dll, such as those contained in Foo.cs - you will not be able to see any of the libraries referenced by/embedded in AssemblyA.dll.
See this answer to a similar question, where the answerer suggests using ILMerge instead.
I have a solution with quite a few projects in it and several dependencies to external DLLs. While trying to build a x64 version of the solution, I found that when building one project several libraries are copied into the output directory which are not mentioned in the project's references or anywhere else within the solution. I figured out that there is a collection of file names called _CopyFilesMarkedCopyLocal, which contains these DLLs. In the concrete case the copied library was used indeed, but it is a x86 library, which overwrites the existing x64 file in the output folder. How does a DLL, which is not mentioned in any project of the solution, become part of this collection? Can some referenced DLL induce further implicit references? Can I control this behavior?
Update: In the x86 build the set of file names contained in _CopyFilesMarkedCopyLocal is what I expected, namely one reference explicitly mentioned.
Well, I'm not familiar with C#. Here's my story:
In the VS2010 solution, there are 2 projects: Entrance, Core and Plugin. Entrance may be compiled into an exe, while the others may produce dlls. Core is added to Entrance's and Plugin's reference. Plugin is set to be compiled to plugin folder. So after compiling, the output directory contains:
entrance.exe
core.dll
plugin\core.dll
plugin\plugin.dll
How can I remove the duplicate core.dll under plugin? Thanks.
In the Solution view of the plugin project, right-click on the core.dll reference and select Properties. Set Copy Local to false to prohibit copying of the assembly to the output directory. Note this will only work properly at runtime if the referenced assembly can be found by the application. In your case it's fine since core.dll is also referenced my the application but that might not always be so.
I have successfully dotfuscated my .dll file to prevent it from being easily read when decompiled...But the problem is, I can't use the dotfuscated dll file because my project can't seem to understand the contents of the file... Could anyone help me please?...
You need to run the obfuscator on the final output (all of the projects together) so that it can handle references across assemblies.
Until that particular dll is obfuscated with option to be used as external library, you cannot reference it within your project.
Few obfuscator, obfuscate all the public classes & methods, hence referencing them is not useful.
I've just started using Team Foundation Server and have added a new Solution that contains a project of type class library. I need to add a reference to the new class library project to an existing class library (dll) that we have created. What is the best way to do this? I've noticed that if I try to add it from the original location as an existing dll, it keeps the original location of the dll. I think what I want is to actually copy the dll to the new project, and add a reference to it locally - but I can't figure out how to do that.
Write a MSbuild/Nant script that build's and copies the dll to a common lib directory. Then reference the lib\foo.dll in 2nd project. Also create the build order.
Can you include both the old and new projects in the same solution? If so, you can reference the project directly (primary artifact) instead of the .dll output (secondary output). This 'just works' when you need to build multiple configurations, such as debug, release, etc.
If that dll is something that will be shared among different libraries and applications, you may want to consider putting it in the GAC. This will also help avoid versioning issues of putting it in a common lib directory (although you could just put folders in the common lib directory for different versions)
MSDN article on the GAC: http://msdn.microsoft.com/en-us/library/yf1d93sz.aspx
Another way that doesn't involve copying the whole project or messing with the GAC would be to:
Add a reference to the DLL to your project
Open the references folder in your project
Right click the DLL -> Properties
Find Copy Local and set it to "True"