I'm trying to use the NetVips library in my VB.NET project, i've added the NetVips.Native.win-x86 in my project from NuGet, the issue is that instead of adding the reference to the Bin folder it's add the NetVips.Native.win-x86 in a folder inside bin called packages and when i'm trying to reference to the library methods in the project i'm unable to...
And if i try manually to add the references to all the NetVips dll i get the error that it's unable to reach assembly or COM.
So how can i make NetVips work?
It is normal behavior.
The NetVips.Native.win-x86 nuget package's runtimes folder's dlls are not the type of COM. Only COM dlls can be referenced under the project. They are native binaries.
And these three dlls are not for assembly references from the author's design.
And that is the folder runtimes folder's function. See this document.
These three dlls from the runtimes folder provide the necessary services for your application when your project is running and deployed. It is just that these three dlls are not the type of COM, which caused your problem.
Instead, you should use NetVips nuget package. The dlls from it are the type of COM. And you can use it.
Update
use Release mode, then move dlls like libvips-42.dll ... from runtimes folder into bin folder, get it.
I'm developing a set of assemblies which contain classes that, using a dependency injection framework, are supposed to be instantiated only by an "InstanceProvider" class --basically that's my gateway to SimpleInjector's GetInstance(). Then I'm packaging these assemblies as a nuget package.
My goal is to enforce that a developer does
var myDuck = InstanceProvider.GetInstance<IDuck>();
and doesn't do
var myDuck = new Duck();
For this, I have to avoid referencing some of the assemblies, the ones that contain the concrete implementations. I still need them to be there though.
So for now, I have them as dependencies in my nuget package. I'm looking for a way to keep them there, but when a developer uses the package for her project, some of the assemblies should not be directly referenced in their visual studio project.
Is this even possible?
Nuspec: can I have an assembly as a dependency but instruct visual studio to NOT reference it?
Since you do not want to those assemblies directly referenced in their visual studio project when you uses the package for her project, only keep them there. You can set those assemblies in the content files or tools files, like:
<file src="\*.dll" target="content\" />
<file src="\*.dll" target="Tools\" />
Check Creating the .nuspec file for some more details.
With this way, those assemblies included in the nuget package, but those assemblies would not directly referenced to the project when you use the nuget package.
Hope this helps.
General answer you can, but you should not bother about it till you really need to develop "plugins" enabled system. This turns debugging more complicated.
But continue to devide interface and realization - it is not related to dynamic loading, but helps you to devide code on layers.
There is a lot of DI tools that can this e.g. Unity. The techinque they use: you configure container in xml file that not require referencing. Then container search for assmeblies and load them.
I have installed the strong named assembly TestReflection into the GAC (I am using .NET 4.0 and VS 2010).
Different versions of the TestReflection DLL are in GAC of .NET 4.0 (C:\WINDOWS\Microsoft.NET\assembly\GAC_32\TestReflection\), however, the assembly does not appear in the "Project" -> "Add reference" box of VS 2010.
How can I refer to my assembly deployed in GAC at design time from another project?
This page says that:
You cannot add references from the Global Assembly Cache (GAC), as it is strictly part of the run-time environment.
Referring to this statement, I would like to know how to make your project's DLL shared assembly for other consumers if it's the requirement?
The dll's shown in the .Net tab of the "Add references" dialog are not actually the ones registered in the GAC. They are found by searching a few paths on your filesystem.
The paths being searched are located by Visual Studio by looking up the following registry entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFramework\{Version}\AssemblyFoldersEx\
There should be some keys added there already, so if you want your own dll to show up on the .Net tab, you can add it to one of the folders defined there. You could also add a new registry key pointing to a custom folder, which would only contain your own dll's.
The GAC is only meant for loading assemblies at runtime after your application has been deployed, so I don't think you should use it while developing. When you deploy your app, make sure to set "Copy local" to false on your reference so the dll won't be copied to the bin folder, and then install it into the GAC and it will be loaded from there instead.
Another simple option would be to manually edit the project file as XML in visual studio (You will have to unload the project first), and simply add node <Reference Include="<name of dll>" /> in MSBuild project file. After reloading the project, VS will pick up the reference without problem.
If you want to add Global Assembly Cache references to your VS2010 project, there is an extension you can use: Muse.VSExtensions.
It has some quirks but does a decent job. Check it out...
The answer is the Reference Paths in the property windows, you have to set it with the GAC path
Please see my post here:
We have several external DLL files being referenced in our Web Application Project. We have a deployment project for installing on the hosting servers. When we were using .NET 3.5 and Visual Studio 2008 the DLL files were being copied to the bin folder. Since we have upgraded to .NET 4 and Visual Studio 2010 this no longer happens, and we are getting server errors since the references cannot be found.
CopyLocal is set to true, and I cannot find anything inside the web.config which suggests this is being set elsewhere.
There is a bug in Visual Studio 2010. By default the XML in the solution file looks like this:
<Reference Include="DevExpress.SpellChecker.v11.1.Core,
Version=11.1.5.0,
Culture=neutral,
PublicKeyToken=b88d1754d700e49a,
processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
</Reference>
Whereas MSBuild is expecting this below, so that the DLL file will be included in the deployment:
<Reference Include="DevExpress.SpellChecker.v11.1.Core,
Version=11.1.5.0,
Culture=neutral,
PublicKeyToken=b88d1754d700e49a,
processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
<Private>True</Private>
</Reference>
The trick is to set Copy Local to False, save the project and then reset it to True - save again. This includes the Private node correctly, which MSBuild respects.
It appears that the default for no included private node (Copy Local) in Visual Studio 2010 is True, while MSBuild reads that missing node as False.
I was getting the same problem and rather than add a "BeforeBuild" step I created a test that simply did this
[TestMethod]
public void ReferenceAssemblyThatDoesNotCopyToBuildFolder()
{
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler referenceThisButDoNotUseIt = null;
}
And that fixed the error The type 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler...' cannot be resolved
Something weird had happened to my deployment project. When I saw it had no detected dependencies, I removed the primary output and re-added it.
The dependencies are now showing up and being placed in the bin folder when installed.
I was getting exactly the same issue. We have a Visual Studio 2008 project which references the EnterpriseLibrary. When we run our integrated build using TFS and our Web deployment project, all the DLL files are copied over. When we upgraded to Visual Studio 2010, TFS 2010 and WDP 2010, some of the DLL file's were missing. Strangely, this only occurs to some DLL files and not others.
For example, we get the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll copied in both cases, but not the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll.
As a workaround I copied the files accross using a "BeforeBuild" step.
It now seems to build OK.
I just had the same issue and wanted to share what I found as it might help someone:
The reason in my case was that the assembly was installed in the GAC during an installation of some third-party application.
If the DLL file is in the GAC, the compiler won't bother to copy it to the destination folder, unless you specifically mark it for "copy local" using the "Private" node in the project file as mentioned by Junto.
The thing is that if you don't add that node, and you develop on one machine and build on a different one, and the DLL file is only in the GAC of the build machine, the default behavior without the private node will cause the file to be copied correctly on the development machine, but not on the build machine.
The bigger problem is if the DLL file is not referenced directly, but the project references a second project that in turn references the DLL file. In that case, you cannot mark the DLL file to be "copy local" in the project, as it is not referenced by it. So if the DLL file exists in the GAC - it won't get copied to your output folder.
Possible solutions to this case are:
Uninstall the DLL file from the GAC
Add a direct reference to the DLL file in the end project(s)
Re-sign the DLL file with a new strong name, which will differentiate it from the DLL file in the GAC.
I am not sure how it was set up in Visual Studio 2008, but I am almost positive that you might have been using the Post-Build event command line. In there you can tell to copy the DLL files you need for deployment. An example is given below:
mkdir $(SolutionDir)\Deployment
copy "$(SolutionDir)Your_Library_Name\Your_Dll_ForDeployement.dll"
$(SolutionDir)\Deployment\
I didn't meet the same problem but similar. I had WPF main project and referenced project where the referenced did not copy. I found that in my case the main project was set for NET 4.0 Client Profile and the referenced for NET 3.5. When I set the main project to 3.5 the compiled dll of the referenced project started to copy.
(I don't know why because I solved it by practice)
I too ran into a similar issue where referenced dlls were not copied into the bin in published folder. I was using a TFS checked out copy that didn't include the bin folder into the application.
-> So just included the bin folder.
-> Built the referenced applications
-> Published the website project
Now I see all the referenced dlls in bin in the published folder
I had a similar issue with VS 2012 Express. I used Tesseract libraries in my project. Everything worked well until I used this project in a solution where were more than one project. Problem was that some DLLs (liblept168.dll, libtesseract302.dll) that are normally placed in folders bin/debug/x86 or bin/debug/x64 were copied only when I rebuilt whole solution.
Changing a single line and building it again caused that the DLLs were deleted and not copied back.
I solved this issue by adding a reference of the project that creates missing DLLs to the startup project.
rzen and others, thanks - your comments led to a solution for us.
We have a project that targets version 10 of the Microsoft.ReportViewer.Common.dll and Microsoft.ReportViewer.WebForms.dll assemblies (separate "libs" folder we created at the 'src' level). But when we did a build, the output included version 12, which was recently installed on the build server.
Using comments here, we ensured that 'Copy Local' was set to True and that the flag was set in the project file. However, it was still deploying version 12. So what we found that did the trick was ensuring that the 'Specific Version' property was also set on the two references. Voila, version 10 of each file is now being deployed!
There was much rejoicing.
JH
If your project does not directly load the library, it won't always be deployed, even if it is referenced explicitly! I got confused because I could see it in a local Bin directory but not when deployed. The dll in the Bin directory was an old file that wasn't removed during Clean which is why I was confused.
A full clean and rebuild and it wasn't in my local Bin folder either which showed me the problem (I only use it in web.config). I then referenced the dll file itself in the project and set it to copy to output to make sure it gets deployed.
We can use the <Private>False</Private> to not to copy the referenced DLL files to the bin directory. This is useful when we are building applications in a separate TFS build server where we need to build the application and not to copy the DLL files to the bin directory.
Check the framework of the project in which the DLL file has been referenced. The framework should be .NET 4.0. Please correct it if the framework is Client Profile.
Adding the parameter
/deployonbuild=false
to the msbuild command line fixed the issue.
Got a similar issue when upgrading old WebSites into WebApplications.
The "Clean Solution" command would wipe out all external DLL files I purposely left in my bin folders.
Besides, it was not possible to bring those DLL back automatically simply by referencing them all, since many of them have the same file name (it happens when you work with many language specific resources)
Like stevie_c did, I took advantage of the Pre-Build command, but made it simpler:
I just used a xcopy command in the Pre-Build operation of the WebApplication project's properties. This way I could bring over the necessary external DLL files just before the build would start.
i have a debug and a release version of an assembly dll.
They are sitting is directories on my computer. For other developers they are sitting in directories on their computer.
For the debug version of the application i want to use the debug assembly. For the release version of the application i want to use the release assembly.
That's the question.
For those not paying attention, there are quite a few issues here. How to reference an assembly on my computer, which after the project is checked into source control becomes a valid path on someone elses computer.
How to have the "References" node be per solution type (Debug, Release).
i tried copying the debug assembly to
\bin\Debug
and the release assembly to
\bin\Release
and added the assembly dll's to source control in the
\bin\Debug
\bin\Release
folders. Then i hope that the assembly would be found in the executable's folder.
Problem with that is that other developer's machines get an error that the assembly dlls could not be overwritten - when CopyLocal is false.
Use a common structure for these DLLs (a common directory-name) and link to this relative.
Example from a .csproj-file:
<Reference Include="utils_xxx, Version=1.2.10.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\common_utils_dllproject_dir\utils\bin\$(Configuration)\utils_xxx.dll</HintPath>
</Reference>
You maybe have to enter this by hand, but once in the repo, it is the same for all. Now you just have to convince your developers to adjust to this directory-layout and -naming.
PS: If you overlooked it: $(Configuration) is the trick to use Release/Debug-DLLs.
Developers must have a folder somewhere on their machine structured like this...
[Parent Folder]
Debug
[Debug Assembly].dll
Release
[Release Assembly].dll
Open the project and add a reference to the Debug assembly from the first step. Check it in.
Have every developer open the project and add a reference path in the project properties. The path should be an absolute path to the Debug folder from the first step.
Have every developer close Visual Studio and edit the [project].user file that is now in the same folder as the project file. Change "Debug" to "$(Configuration)". Save and close.
This should now work. If you select the reference in the Solution Explorer and look at the Path property in the Property Grid, it may not be correct. It's just a VS issue. If you test building in Release and Debug, it should work.
This works because the reference paths that developers set are stored in a user file that never gets checked into source control. Therefore, the paths can be different for every dev. This solution is basically stolen from Leonidas' answer but uses reference paths.
Disclaimer
I don't know all the details of your situation, but I personally wouldn't do this. I would probably GAC the release version of the assembly on the developers' machines. Then I would have a build script that ran on a server that would take care of your complicated scenarios.
Include the project and link to the project? dont know if that does work in your situration...