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.
Related
I have to create a COM library from a C# project, but I'm pretty stuck with referencing the external libraries.
I have set "Make assembly COM-Visible" in the project's properties and when I build it creates the dll and it puts all required dll's in the bin/Release directory.
Libraries used
All libraries are .NET imported with NuGet or System libraries.
Creating the .tlb file
When I run a command to create a .tlb file, it is created, but it also shows a warning:
tlbexp.exe "MyLib.dll"
TlbExp : warning TX00131175 : When cross-compiling, all type library references should be included on the command line to ensure the correct bit-specific type libraries are loaded.
Assembly exported to 'C:\Workspace\MyProject\bin\MyLib.tlb'
It looks like this library is ready to be shipped, but I'm wondering if I can just ignore the warning.
And, what is the best way to ship this COM-Visible library?
Can I just ship the entire bin/Release directory, or should I use another method?
Well the .tlb is needed just to reference your library from a development tool ( for example Visual C++ ), referencing correctly does not mean that program, after compiling correctly, will work. This because you need to proper install the dll on the target machine, typically you need to xcopy the dll with all dependencies, and then use regasm.exe ( specifying the /CODEBASE flag I suggest, so you can point surely the dll you want on your file system ). Of course even proper Framework has to be installed too.
If someone could clarify the following, with regards to c#, this would be great.
Say I have a web project (webproj1) and a class library (classlib1).
webproj1 has a reference to classlib1.
classlib1 also has a reference to a third party dll (thirdpartydll).
When built, the \bin folder of webproj will obviously contain classlib1.dll, but should it also contain a copy of thirdpartydll.dll(which is referenced from classlib1) or is it somehow 'embedded' in to classlib1.dll?
You need it separately when the assembly cannot be found in for example the GAC.
See http://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.110).aspx
You could embed it using ILMerge (http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx)
I have an application written in C# which interfaces with some custom hardware using a vendor supplied .Net assembly. The .Net assembly in turn loads another DLL at run time. I can add the vendor supplied assembly to my project but when I run it, the vendor assembly complains that it can't load the required DLL. I can work around this for the moment by copying the DLL to the bin\Debug and bin\Release folder.
The problem is that I will need to distribute this application to clients at some point and they will not have this DLL in place. I can't see how I can make the solution require it; I can't add it as a reference since I get the error "A reference to foo.dll could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component."
I can't convert the DLL to a .Net assembly using TlbExp, it gives an error "The module was expected to contain an assembly manifest."
I thought if I published the application via "click once" that I could declare the dependency there but I don't see any way for this either. I also tried adding it as a file resource but this didn't seem to help.
I can see other questions on SO relating to how to invoke functionality in an external DLL but in this case, I just need a way to bundle the DLL with the project.
Thanks.
Indicates that the attributed method is exposed by an unmanaged dynamic-link library (DLL)
The DllImportAttribute attribute provides the information needed to call a function exported from an unmanaged DLL. As a minimum requirement, you must supply the name of the DLL containing the entry point.
For further reference go here
Link to Review
You could add the dll as a resource, write it out as a byte[] to a file on loading, and do an Assembly.Load() at runtime for deployment.
You might have to use an AppDomain.AssemblyResolve Event to make sure the assembly resolves in case of multiple versions.
you could add both (all) of the dlls in your project as references and mark them as "copy local". That should do it unless the first DLL expects the second DLL in a specific place.
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.
I'm attempting to implement a C++ DLL (of my own creation) that uses the Intel Performance Primitives in a C# forms application. I'm getting a "DLL Not Found Exception" when I attempt to run the program. One possible reason put forward in other posts on this site is that there are dependent DLLs that must be referenced and in fact after downloading DpendencyWalker I found that my DLL uses "IPPS-7.0.DLL".
My problem is that it is unclear to me how to reference these dependent DLLs. I've added the IPPS-7.0.DLL containing folder to referenced paths as well as added references to the "IntelCppOptPkg" and "IntelLibOptPgk" assemblies but this has not solved the problem.
So, am I correct in believing this is the problem? And if so, how does one reference a depedent DLL in managed code?
Thank you.
You don't reference them, they are not .NET assemblies. You just need to make sure that the DLL(s) get copied to your build directory. Easiest way to do that is with Project + Add Existing Item, select the DLL from wherever it was copied. Then select the added file and in the Properties window set Build Action = Content, Copy to Output Directory = Copy if newer. Checking-in the DLL(s) in source control is generally a good idea btw.
Managed code can not reference unmanaged dll the same way it references managed assemblies. Managed references actually change the meta data of your assembly:
The compiler records static
references in the assembly manifest's metadata at build time.
...
The preferred way to reference an assembly is to use a full reference,
including the assembly name, version, culture, and public key token
(if one exists).
Native dlls simply don't have this .NET meta data associated with them. They have to be copied manually in the Post Build step or during deployment. There is a workaround but I don't think it will work if your managed app is platform independent (Any CPU) and you have x86 and x64 versions of unmanaged dlls.