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.
Related
currently I am working on myDLL.dll. But myDLL.dll needs to include another Dll: D:\their.dll. But their.dll depends on a couple of other Dlls (D:\other1.dll, D:\other2.dll).
I have included their.dll into my project (as project reference)
<Reference Include="theirDLL">
<HintPath>D:\their.dll</HintPath>
</Reference>
And thus, their.dll is used in all projects which use myDLL.dll.
But I don't know how to include the other dlls, so that they are copied in the same path as myDLL.dll and their.dll during compiling.
At the moment I use pre-build events to copy the other dlls into the projects which need myDll.dll (and therefore their.dll). But this is a pain.
Any suggestions?
Best regards,
HarryKane
Add each .dll file to your project and (assuming you are developing in Visual Studio) then under solution explorer -> properties of each .dll file, select copy local and set the value to true, then each necessary .dll will be copied to the bin folder when compiled.
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.
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.
How do you determine what executable and DLL’s a C# Visual Studio project produces?
In Visual Studio 2010, where do you go to see what the name of the executable that a project produces.
A C# project will produce just one assembly output (DLL or EXE). Additional assemblies will be included from references that are not installed in the GAC. For instance, if you add a reference to another project in the solution, it will copy that project's output assembly to the current project's bin folder.
Check the bin folder after build to see what was generated and included. e.g. <project folder>/bin/Debug
I think it's the <AssemblyName> section in the .csproj file. Combined with the <OutputType> section to determine the file extension.