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.
Related
I would like to have a smooth and efficient installation of the solution, but what I "inherited" is very far from that, and the guy who programmed most of it has left the company.
At present I am trying to install it on a test-server, and not all the dll's land in the correct places after the installation.
Firstly, if I use log4net in a project, then I need the log4net.dll in the folder after the installation (I guess). How do I get the log4net.dll to be copied with the project dll?
Secondly, Project A expects Project C's dll to be in the GAC or so it seems when I debug in Visual Studio and check where the modules are loaded from.
I also see that this is entered in the post build event commandline of Project A:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\GacUtil.exe" -i "$(TargetPath)"
copy "$(TargetPath)" "C:\Program Files\MySolution\bin"
So how do I get Project C's dll into the GAC by way of the installation? I get an error on the Test Server because it can't load C.dll.
UPDATE WITH MORE DETAIL
After the solution has been installed with Windows Installer, a few folders are created in the parent folder such as Apps, bin, Engines, Service etc.
In the Apps folder, I have A.exe, which is looking for C.dll. However, C.dll lands up in the bin folder. As mentioned above, during execution of A.exe, it actually loads the modules of C.dll from the GAC (and on my laptop, those files are in the GAC because of the post-build event command line specified in the properties of Project C, but not in the GAC of the Test Server to which I am trying to install this solution).
So yes, I assume I could run something like this:
gacutil -i C.dll
after the installation, but it doesn't seem right.
There are two parts to your question relating to the GAC, and ensuring DLLs are copied.
GAC
Check out this link (https://msdn.microsoft.com/en-us/library/dkkx7f79%28v=vs.110%29.aspx) from MSDN on how to install into the GAC. The key thing is it must be strongly named or it will fail.
DDLs
Depending on how you are referencing Log4Net, there are a few ways to do this.
If you can add a reference in your project, make sure the property CopyLocal is set to true
If you just have the file locally, you can add it to a sub folder of your project with a symbolic link (https://support.microsoft.com/en-us/kb/306234), and then set the CopyToOutputDirectory property.
Hopefully these help you along.
I found what I was looking for!
Select the Setup project, then go to the menu "View" -> Editor -> File System.
It seems you can specify where the dlls must go, and what should be copied to the GAC during installation.
TFS (2012) Build is checking C:\Windows\Microsoft.NET... for a few of my project references even though the dlls are included as project references (set to copy local) in a folder I'm checking in.
Building outside of TFS, both in VS and using MSBuild.exe command line succeeds.
I can see in the errors and warnings that the references it is complaining about not being to find 'Could not resolve this reference. Could not locate...' are all due to it simply not checking in the checkin dependency folder as defined in the proj file.
Any ideas on how to correct this?
I believe there is a "check gac first" rule for DotNet dependency resolution.
So I do my references like this.
\MySolution.sln
\BALLayer\Biz.csproj
\DALLayer\Data.csproj
\PresLayer\MyWebsite.csproj
\ThirdPartyReferences\
\ThirdPartyReferences\SuperCoolDll111.dll
\ThirdPartyReferences\SuperCoolDll222.dll
\ThirdPartyReferences\SuperCoolDll333.dll
This way, all csprojects reference the needed dll(s) with a relative path.
All cs projects reference the SAME dll.
This has helped me avoid the "I'm gonna look in the GAC no matter what you want me to do" issue.
Nuget does this similarly.
\packages\
\packages\repositories.config
\packages\SomeLibrary\SomeDll.dll
\packages\SomeLibrary\MyNugetDll.dll
and cs projects reference the same .dll with a relative path.
............
Footnote:
Open up your .csproj file(s) in notepad, and look for the HintPath.
Mine always say something like
<Reference Include="MyNugetDll.dll>
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\SomeLibrary\MyNugetDll.dll</HintPath>
</Reference>
OR
<Reference Include="SuperCoolDll333.dll>
<SpecificVersion>False</SpecificVersion>
<HintPath>..\ThirdPartyReferences\SuperCoolDll333.dll</HintPath>
</Reference>
.........
But I think the crux of your issue is "copy local" and the "gac first" rule.
.........
PS
Here is another question that discusses the order...better than I could.
In what order are locations searched to load referenced DLLs?
EDIT::::
So lessons learned:
If you have your third party references checked into source control, and the build machine says "i cannot find xyz.dll", then make sure that dll is actually in source control. There are alot of "voodoo" paths on (the local development) machine with visual studio installed, and subsequently will NOT be on the "build machine".
If you use nuget and you check in your dlls, make sure they are all checked in. You might add a new entry to the packages.config and then forget to put the actual dll(s) into source control.
There are some ways to use nuget that you only put the packages.config in source control, and not the third party dlls. Check the comments of this post for articles about that.
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.
I have a c# solution with some projects. For the solution I have created a folder for extenal libs. I have copied some Telerik-dll's from the instalation to the libs folder.
Now my problem:
When I add the dll's to the projectes (I choose the copied dll's from the libs folder) Visual Studio takes always the dll's of the installation source and not the dll's of my libs folder.
How can I fix this? I'm afraid that my colleagues could not compile the solution because the dll's are referenced to a missing directory (would happen if they don't have installed the correct Telerik version).
Thanks
Edit:
For example:
I reference with the file chooser
"C:\vendors\Libs\Telerik.Windows.Controls.Input.dll"
Visual Studio references
"C:\Program Files (x86)\Telerik\RadControls for Silverlight Q2 2011\Binaries\Silverlight\Telerik.Windows.Controls.Input.dll"
Properties of the references - set Embed Interop Type to false and set Copy Local to true
We have an application wrote in C#, which broken into several projects. These projects have reference to others.
When someone gets the source from version control and opens the solution contains these projects on its own machine, Visual Studio cannot find the references between projects, even though referenced project is build successfully. That person have to re-add the reference to solve this.
Seems to me that Visual Studio keeps some data in `suo' file, so next time it knows where to find that re-added reference, and this problem won't appear next time the person opens the solution.
Since `suo' file keeps absolute path to references, we cannot commit it in our source control.
The problem is, We've got a separate machine, which builds this big application automatically (as our nightly-build releases) When the build-automation tool opens the solution, and calls Visual Studio's compiler to build it, the references cannot be find. (automation tool cleans everything, and get the latest version of the source again, so it dose not have `suo' file.)
Any solution?
Extra information
Visual Studio version: 2008 - 9.0.21022.8
.Net framework: 3.5 SP1
OS: Windows XP Professional (SP2 & SP3 - we have both of them)
Update
Seems that Visual Studio changes <ProjectReference> tag to <Reference> in `.csproj' files sometimes. Our developers commit the file, and this problem happens.
I couldn't find if it's a bug in Visual Studio. The only solution that comes into my mind is to write a tool to correct this in `.csproj' files, before pass it to the automation tool.
References are defined in the .csproj file for each project. They may be defined in one of two ways (in my experience).
Either with a hint path to find the referenced assembly:
<Reference Include="CommonServiceLocator.NinjectAdapter, Version=2.2.0.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\Dependencies\CommonServiceLocator.NinjectAdapter.dll</HintPath>
</Reference>
Or without one:
<Reference Include="CommonServiceLocator.NinjectAdapter, Version=2.2.0.0, Culture=neutral, processorArchitecture=MSIL"/>
You need to make sure that the references are in the first form, that the hint path exists, and that it's a relative path so that it works no matter where you check out the solution.
You can edit the .csproj files either with an external editor, or by right clicking the project, choosing "Unload project" from the context menu, then right clicking again on the unloaded project and choosing "Edit projectname.csproj". After you 're done editing, right click again and reload the project.
Open the project files (*.csproj) and look what are they referencing. Mostly sure the paths are relative to the solution path and your build script might use other paths.
One way of solving this:
Define an environment variable SOURCE_PATH that holds the path to your sources root folder
Edit the project files so they have reference relative to this path (use $(SOURCE_PATH)) in csproj files to reference it
Repeat steps 1-2 on each dev/build machine and add extra env variables if needed.
PS: The *.suo should not be in the version control system.
Why won't you use msbuild rather then automated visual studio compiler?
It's a bug in VisualStudio 2008 and before that.
If you open a solution that contains a project that have reference to another project, but referenced project doesn't included in the solution, VS finds the referenced project, but changes the reference in a way that it refers to the output DLL, not the project itself.
This bug is fixed in VS2010, and MSBuild 4.