I have a library with both managed and unmanaged C#, C++ dll files. I want to reference it from F#. Where can I place the C#, C++ dll files? I can not place them in the application folder (I must have copy local = false) and it will be only me who will use the program. I have tried windows/system32, GAC using setup and adding PATH variable pointing to a folder with all the dll files but none of it seems to work.
Thanks for any hint
When building your application in Visual Studio, it looks for the references in all the default folders (depending on your OS, .NET Framework version and other things) but also in locations you specified in the project configuration. Right click on the project in Solution Explorer, click Properties and go to the Reference Paths tab. Add C:\MyDllFolder or anything.
If you do this in all your applications which are using that dll, you could just have it sitting there once.
You can specify dll locations MSDN : Specifying an Assembly's Location or maybe use something like
Assembly.LoadFrom
if you want dynamics.
Related
I have written a C++/CLI wrapper for some unamanaged dll's (OpenCV). Everything works fine until this point. Now I would like to store the dll's in a subfolder, so the final application structure would look like this:
bin\
MainApp.exe
wrapper.dll
Wrapper\library1.dll
Wrapper\library2.dll
Also, I would like to configure this in the Wrapper project, so I don't need to care about this in any other project using wrapper.dll
I have found several posts talking about this, but none of them seems to match my needs:
Setting the path in app.config file: wrapper.dll does not have an
app.config file, and I would have to add this reference in every
executable project using the dll.
Setting AppDomainSetup.PrivateBinPath: this could be a workaround, but I'm
not sure whether it works for unmanaged dll's.
Using ILMerge: Does it work for unmanaged dll's along with C++/CLI dll?
Ideally I am looking for a property in Project settings to add this subfolder, so every Solution including my project will look for the unmanaged dll's in the right folder.
The problem here is that the DLL's are usually loaded by Windows, and they're loaded when your application starts. Windows starts by looking at the EXE, finds what DLL's it needs, loads them, and then continues to load DLL's needed by DLL's. This is not specific to C++ or C#.
.Net does affect DLL loading, but that's not applicable to native DLL's.
So, what can you do? One solution is to not let Windows load your DLL's. Visual Studio has a DelayLoad option. This uses LoadLibrary at runtime. And with dliNotePreLoadLibrary you can control where it's loaded from. Since this happens at runtime from your DLL, the executables don't need to do anything.
I am using Visual Studio 10 within a C# MVC appliction.
I have a qustion on a .dll reference. I am using a third party reference called
Ionic.Zip.dll. What I am not sure about is that it currently points to a location on my C: drive.
How and what is the best practice for me to put this .dll so that when I check in the project, others can also see this .dll without it blowing up.
Thanks
I would typically put a Library folder in my application structure, place the 3rd party dll in that folder, and then reference that dll. Then ensure that the library folder is checked into your source control.
Now, anyone that pulls your source will have the required dll.
Even easier...simply add a reference to DotNetZip via NuGet, the Visual Studio Package Manager:
http://nuget.org/packages/DotNetZip
And you shouldn't have to worry about it.
The best way is to use Nuget.
But in some cases Nuget is not available or not getting compative, so as our friend says, its better put a Library folder in application structure, place the 3rd party dll in that folder, and then reference that dll. Then ensure that the library folder is checked into source control. Now, anyone that pulls source will have the required dll.
I have a solution with a C++ dll project and a C# project that uses it. The problem is that the build path of the c++ project is in the solution folder and the c# is in the project's bin folder (each nested with debug/release), so the DllImport doesn't find them.
Is there a standard way to fix this?
The way you are supposed to do this is to set the build path for both projects to the same 'bin' directory... preferrably one for the solution, not a project. Then just make all projects build to that one folder. You can change that from the Project settings.
Another technique is to use a post-build step for the C++ app that copies the DLL to the C# project's folder. That way you don't actually change any paths. You just copy over a DLL. Be careful here though because when you clean the C++ file's project, you may actually still have the copy in the C# projec'ts bin directory leaving you scratching your head as to why things aren't happening as expected.
Alternately, you can deploy the C++ DLL to a system path (also as part of a post-build step) but you'll have the same issues as stated above.
For debugging, I'd recommend these in the order presented.
I make use of the Belgium Identity Card SDK for reading data from a idcard.
The SDK exists of 2 components: interface dll and a wrapper dll.
In VS2010, i can make a reference to the interface dll, but not to the wrapper dll, so I put it manually in the bin folder. When I migrate my application to another pc on the localhost, it is not able to find the wrapper dll.
Not even when I (on the 2nd pc):
-installed the sdk.
-put the wrapper dll into the bin folder and system32 folder
In visual studio, properties of the interface dll, I've set "Copy Local" to true.
What can I do?
This could just be a difference in path names between machines.
I would create a folder at the top level of your solution and place these DLLs in there. Call it something obvious like "Solution dependencies". Then you can reference them as needed and set them copy to local as required. You wont always be able to reference a DLL, especially if it isn't .NET compatible.
I'm curious about your statement of interface and wrapper dlls. Is the wrapper dll not meant to be a .NET wrapper for a C++ style dll?
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"