We Keep Coding

Visual studio 2010 assembly references

I've got a project on a computer with installed devexpress line for win forms. In VS2010 I add references to some of devexpress .dll(s) and mark those references as 'Copy Local' and build project. Than I send a folder with a project to another user whose machine has not installed devexpress on it. When he opens the solution all devexpress references are shown as broken and the assembly won't compile.
The output is as the following:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5):
warning MSB3245: Could not resolve this reference. Could not locate the assembly
"DevExpress.Data.v13.1, Version=13.1.8.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a".
Check to make sure the assembly exists on disk.
If this reference is required by your code, you may get compilation errors.
How to add references to the assembly correctly so as I can open it on a machine with no such .dll(s) installed?

"Copy Local" option is copying files to the published directories after building process.
You can include these dlls in the separated solution folder, reference VisualStudio to them and commit this folder with solution to svn or tfs.

In order to do that you need to add the references via Add Reference... / Browse. In the csproj file for your project you should have something like:
<Reference Include="Name.Of.Assembly">
<HintPath>Relative\Path\ToAssemblyFile.dll</HintPath>
</Reference>
BUT VisualStudio tries to be smart and adds the Reference to the installed assemblies, even if you choose Browse... to add them.
You can either:
Not install the DevExpress package and only copy the DLLs to your development machine
Manually edit the .csproj file
Either way, you need to keep the DLLs somewhere. I usually put them under source control.

To achieve this, you should add the DevExpress (or other third-party) assemblies to a folder under your solution root directory, then reference the assemblies in this folder rather than referencing the DevExpress install directory.
You should also add the third-party assemblies to source control, so they're available to all developers.
If the other developer hasn't installed a DevExpress license, it will still build, but will display a nag screen at runtime.

VS Solution with C# project dependant on C project, best pratice [duplicate]

How can I set up a project in Visual Studio to copy the third-party DLLs that one of the project's references depends on?
I have a main application project and a class library DLL. The main application references the class library DLL, and the DLL itself references some third-party DLLs. When I compile the main application, it automatically copies the class library DLL to its output directory, but it does not copy the third-party DLLs.
I do not want to add references to the third-party DLLs from the main application project because the main application does not use them, they're only used by the class library.

You can achieve this with the project properties window. Visual Studio allows you to define events to occur, before, or after building. To get to the project properties window simply right-click on your project in the solution explorer window and click on 'properties'. From the left hand side go to the 'build events' tab.
In the post-build box type in a few copy commands. For example:
copy "$(SolutionDir)mydll.dll" "$(TargetDir)"
Where $(SolutionDir) and $(TargetDir) are both predefined variables. The standard syntax is as follows:
copy "source directory and file name" "destination directory"
If you click on the 'edit post build...' button it will bring up a box which has a listing of these predefined variables that you can insert (like $(SolutionDir) and $(TargetDir))
As a side note, this is a useful process for copying other files, such as custom configuration files, images, or any other dependencies your project may have.

The following fragment works for me:
<Project>
...
<ItemGroup>
<Content Include="Path\to\dll\dllname.dll">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>
</ItemGroup>
...
</Project>
This works for C#.
For native C++ it still copy dll to output folder, but this dependency is not visible in Visual Studio, it should be edited in project file directly.
To test on non-trivial example
I tried to run C# project A which depends on native C++ project B. B projects depends on thirdparty native dll C - this dependency is implemented via fragment above in project file.
When I build A, C is copied to binary folder.
I tried it in Visual Studio 2010.

Take a look at this solution provided by Alex Yakunin
http://blog.alexyakunin.com/2009/09/making-msbuild-visual-studio-to.html
It worked for me really nicely - the scenario being DevExpress libraries expressly used had other dependencies which caused problems when deployed)
Note 1: Visual studio 2010 seems add referenced dlls automatically, however msbuild didn't. So Alex's solution worked since the release scripts used msbuild.
Note 2: Also had to make sure that for the referenced libraries (those which were referenced in code) copy-local was actually set to True in the csproj, even though the Solution Explorer said it was. The best way is to set copy-local = False, Save, set copy-local = True, Save.
These two steps - copy-local=true for referenced libraries and adding msbuild targets for the indirect references automated the build setup for me.

I would not recommend doing this. You end up with an N^2 explosion in the number of assemblies being copied around (and potentially, being rebuilt). If possible, you should have all of your projects place their assemblies in the same $(OutDir). If you're using TFS, Team Build does this for you.

I don't like to have my dependency files located in the project root folder but in a subfolder. But the files has to be placed in the root folder in the build folder.
My build events look like this:
Command: call xcopy /S /Y "$(SolutionDir)Dependencies\*.*" "$(TargetDir)"
In case "Dependencies" also contains subfolders, as mine does.
/S means to copy subfolder also
/Y means to not prompt for overwrite confirmation
Other xcopy parameters can be found at: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy

Go to the main application, references, to your class-library reference.
Set "Copy Local" to True.
It will now copy the bin directory of your class-library into the main application bin directory. Including any sub-dependency third-party dlls.

If you want to copy new file only in post-build, you can also use xcopy with flags /i /d /y
xcopy "$(ProjectDir)SubDir\*.dll" "$(TargetDir)" /i /d /y

100% sure this will work.
Just replace dll with your personal ref. file
<Reference Include="Xceed.Wpf.Toolkit">
<HintPath>..\..\..\3rdParty\Extended WPF Toolkit-2.2.1\Xceed.Wpf.Toolkit.dll</HintPath>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<SpecificVersion>False</SpecificVersion>
</Reference>
<Content Include="..\..\..\3rdParty\Extended WPF Toolkit-2.2.1\Xceed.Wpf.Toolkit.dll">
<Link>Xceed.Wpf.Toolkit.dll</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<SpecificVersion>False</SpecificVersion>
</Content>

I'm not really aware of any way to do this other than adding a reference to said .dll in the project itself. We've run across this in some of our own projects here, and the only solution we've found is to add the reference. I want to say that one of our developers did some research and found this to be the only solution, but don't quote me on that.

DLL reference location

Okay, I asked this question the other day, and it was closed due to my vagueness. I'll try to be more specific. In a project, say C# (using Visual Studio), I add a reference to a dll (right-click References->Add Reference), and the location of said dll is in C:\Blah\Foo. Now, if I move the exe that is built over to another machine, will the location of the dll need to be with the exe, or will it need to be in C:\Blah\Foo? Thank you.

When you add a reference in the way you've described it is copied to the output folder (same as the exe file). Look in the properties of the reference (F4) and you will see an option called "Copy Local", if this is set to true then the DLL will be copied to the same output folder as the EXE file.
So when you deploy your application to another machine you will need to copy the exe and all it's referenced DLLs to the deployment location. Windows will search for DLLs in a number of locations, the first of which is the same folder as the EXE file.

Typically, you'll just put the assemblies in the same folder as the application, which causes it to be in the default probing path, and get found (for most applications), but there are many other options depending on the type of application. When you define your reference, there is the option to "Copy Local" - which causes the assembly to be copied to the application's output folder. If you leave this set to True, the assembly (DLL) will be with the .exe, and typically "just work."
The full process the runtime uses is covered on MSDN in How the Runtime Locates Assemblies. In particular, the topic titled Locating the Assembly through Codebases or Probing covers how the assemblies are located in detail, which depends on a lot of factors.

The DLL should be with exe file. Have a look on this link to see where .NET serach for DLL In what order are locations searched to load referenced DLLs?

The dll could either be installed in the GAC or be present with the EXE in the same directory.
EDIT: The above mentioned are only just a couple of locations to resolve references.

When you add reference, you add path on your csproj on this assembly, dont you must just ensure that you can reference this dll.
When you deploy, it's another question, because your dll is copied on your Bin directory.
If you deploy you check your path of assembly in your csproj, and ensure that you deploy your assembly
Nota : check CopyLocal Property of your refrence
2 Other solution :
You can use GAC Global Assembly Cache in order to share your assemblies
Tools : Gacutil.exe in order to set assembly

Missing references when using Visual Studio C# Express with Dropbox?

My colleague saved a visual studio C# express project on a dropbox folder and I opened it from this folder. We addded the reference paths but some namespaces are still not recognized. What should we do and is it possible to work together from dropbox on the project?

The way that we have resolved this is to include all external, non-framework assemblies required by the application in sub-folder relative to the project and then when the assemblies are referenced, we edit the csproj file and ensure that the assembly references are relative instead of absolute.
For example:
Solution Folder
Assemblies
MyAssembly.dll
Project Folder
MyProject.csproj
MyProject.sln
If MyProject.csproj has a reference to MyAssembly.dll, then the reference in the csproj will be something like:
<Reference Include="MyAssembly">
<HintPath>..\Assemblies\MyAssembly.dll</HintPath>
</Reference>
This practice ensures that all projects are always built and tested with the exact same set of DLLs and are not influenced by different updates installed on each developer's machine.

Whether or not to include external DLLs in C# project

Our project has a lot of external DLLs, most but not all of which are 3rd party DLLs.
Currently we do not have these DLLs included in our project. They are included in SVN and given a path to our build output directory. So, after building our project the neccessary files are there, because of SVN, but the project itself has no knowledge of them.
My feeling is that we should have a folder under the root of our project named something like Dependancies or ThirdParty with all of the DLLs included there and set their build event to copy to the output directory. They would exist in SVN as well, but in the same structure as the project, not in the build output directory.
The project itself only references one of these DLLs called CommunicationProc.DLL. The CommunicationProc.DLL then references all of the other DLLs. We have numerous DLLs to support different types of radio. So not all DLLs will be used, but any one of them may be used depending on the radio type.
As to whether or not the DLLs should be included in the project we have differing opinions internally, some of the team beleives they should only be in SVN and not part of the project itself.
Of note is that this are not .NET DLLs, most are old C DLLs.
What is the accepted practice? Can someone please provide me with a compelling arguement one way or the other as to whether to include them in the project or just SVN?

Its better to have them in a folder on source control and then copy them over to the debug folder on build event. This way you can manage their versions. If a newer version of some dll comes then you can replace the old one and put some comments with check in. Also if you are working in a team, then instead of copying files from debug folder to each team member, you can let each team member to use the same set of dlls from source control. If you are developing some control and want your customers to use that control then its easier for you to have a set of dependent dlls some where so that you can give those to your customer along with your .Net dlls.
I had the same issue with some un-managed dlls and ended up putting them in a folder so that all the team members have the same version of the dlls. Hope this helps.

I include a project that has no code but contains a folder where all the external assemblies and their dependencies are kepts. For each file set the Build Action to None and Copy to Output as Do Not Copyp. The project then references the binaries from this location. In your other projects, reference this special project. When you build, because the special project is referenced and it references all the needed dependencies, the binaries are copied as needed.
If you do not want a special project, still create the folder in your main project, added the assemblies, set their properties, then reference the assemblies as needed.
This gives you complete control over the versions and output, and more importantly, it is simple.