I have many different c# projects in a solution where one assembly is dependent on others. I have them all building in the correct order. I also have CopyLocal set to false for all references. However, when the builds of assemblies are done further down the stack, some of the assemblies are getting copied to the bin\debug folder. Why is this happening? How can I stop this since it is taking up disk space for no reason. The only project being built that needs all the assemblies is the last one built which is the .exe assembly. I have a separate script that copies all the assemblies to this bin\debug folder as I need after the build process completes.
Setting copy local to false only works if assemblies are in the Global Assembly Cache. Any assembly which isn't GACed will be copied into a project in which it is referenced.
You could add a custom MSBuild task to your project which deletes them afterwards from all other projects aside from your main one.
Related
I have a solution with two nuproj projects, say A and B.
Both projects contain only props and targets files (so NO assemblies or PDB files) and they both generate NuGet packages.
Now, A has no reference and it is an internal dependency, whereas B references A plus other external NuGets.
Then I have an MSTest project that dynamically invokes MSBuild on a project which references B.
All works fine in Visual Studio and the tests pass. However, NCrunch compiles with warnings for the project B.
WARNING - ........\program files (x86)\microsoft visual studio\2017\professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets (2110, 5): MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly 'A.nupckg' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Infact, no NuGet package is generated for the A project in the NCrunch solution directory (the package is correctly generated in Visual Studio).
I have also tried to set the following properties for the A and B projects:
Instrument assembly = false
Prevent signing of output assembly = false
Implicit project dependencies = true
nothing changes and the warning is still there and no NuGet is generated for the A project (all the source files and dependent assemblies are in the NCrunch solution folder).
And Copy referenced assemblies to workspace is set to true.
Is there any known issue with using NCrunch with .nuproj?
Is it possible in MSBuild 4.0 and/or 4.5 to specify additional files to be treated as a manifest output of a project by its dependencies, and copied with the binary project output, whenever that is copied? Ideally, I want to create some files beside a .dll during build, and would like these files to stay in the same folder as the .dll whenever it is copied to a directory of a project depending on it.
If this is not clear, I am thinking of .pdb and documentation .xml files created by the C# compiler. These files treated specially: Whenever another project requests the .dll be copied locally into its binary directory, these files go with the .dll. Can I augment this set with my own special files?
This is not possible, and here is why. Actually, there is no concept of project output accessible externally between MSBuild projects. Rather, when a reference to a project is added, the SDK-provided build framework (based on MSBuild scripts) looks for a few specific files matching the name of the referenced DLL, and copies these files with the DLL itself into the current project output directory (assuming CopyLocal is set, which is probably true for a referenced project).
In framework v4.0, this is done by the task ResolveAssemblyReference which is called from an identically named target from the file %windir%\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets. The task looks for specially named files placed beside the target DLL, including its matchin PDB files and an XML documentation file. Other files are also discovered, as I infer from the decompiled source.
So nothing in a given project specifically marks these files as somehow "exported" from the project. The magic happens on the pulling side.
Project A references Projects B. Project B references Project C. Project A does not reference Project C.
This builds fine locally. However, on the build server it errors out because Project A does not reference Project C.
Error:
error BC30009: Reference required to assembly 'ProjectC, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' containing the implemented interface 'ProjectC.IFoo'. Add one to your project.
How can I catch this before committing?
Edit:
Here's more info on my issue: http://sstjean.blogspot.com/2006/11/msbuild-cant-find-secondary-references.html
Here are two things you can do as a best practice to ensure your projects are referenced correctly and MSBuild will be able to find your referenced projects correctly.
Use project references instead of referencing dll's. Create a folder called dependencies or libs and place any referenced dll's within this folder.
Check the build order and project dependencies tab for each project by right clicking project and selecting project build order. Ensure that every reference in your project is being built by that project.
MSBuild does not know what a .sln file is. MSBuild reads and parses the .sln file to determine the build order of projects. By having project references MSBuild will be able to traverse and build the projects in the correct order. See below link for more information.
This link also helps explain why you would see different behavior and how to catch it.
Visual Studio Integration (MSBuild)
Within Visual Studio, the solution file and project build ordering are controlled by Visual Studio itself. When building a solution with msbuild.exe on the command line, MSBuild parses the solution file and orders the project builds. In both cases the projects are built individually in dependency order, and project to project references are not traversed. In contrast, when individual projects are built with msbuild.exe, project to project references are traversed.
When building inside Visual Studio, the property $(BuildingInsideVisualStudio) is set to true. This can be used in your project or .targets files to cause the build to behave differently.
Go to your project references and right click Oracle.DataAccess then go to properties and in properties page make sure that specific version is false and copy to local is set to true.
I am using MSbuild for CI tool and have many C# projects located in different directories. There many dependents projects as well. Some developers use Add Project option to add project and some directly connect to .dll file and i have no control over it. some cases all projects added to a solution So if i compile that solution then it takes care of all dependencies. But i do not this in my auto build. I want to compile all .csproj and output .dlls to a particular folder and then all projects including web should point to this folder for reference.
Want to know if this a ideal process?
In my Project we do the same and it works. Sometimes we have project references and sometimes we have direct dlls references in a folder called "Solution DLLs".
How we do it:
The reason is that we have many projects (120 or more) and we have split them in several solutions. One of the solutions is for framework and commmon dlls. These Dlls are copied in postbuild scripts to a "Solutions Dlls" folder and checked in in TFS. Later our build scripts copy these solutions dlls...
How it works:
It works "fine" and is acceptable. But many problems came (and sometimes still come) with postbuild scripts not working fine. We are aiming to reduce the number of csprojs to 50-60 and use again one single solution.
i did a build in vb.net and got one exe file
however, when a user runs the file, it says it is missing one of the libraries (itextsharp).
so the question is, if there is actually a build option in vb.net, why does it not include the library in the same exe file?
You can distribute the iTextSharp DLL with your application. The easiest way to do this is to simply include it in the same folder as your EXE. The DLL should be output to your Project's Debug/Release folder each time you build assuming you've added it as a Reference in your project and the Reference's 'Copy Local' property is set to True.
If you want to distribute one EXE and include the iTextSharp in that, you can use the ILMerge tool (or alternately Gilma from SourceForge) after you build your EXE.
in the properties for the reference set the Copy To Output to Always
ITextSharp is not a library linked in your project output; it's an assembly referenced by your project output. And while VB.Net builds one executable from your source code, the CLR still needs all the referenced assemblies in the same folder as your executable.
To make everything work, you can distribute ITextSharp assemblies along with your app. Alternatively, if you indeed need only one file, you can use ILMerge on your project output and the assemblies you want included. However, you might need to determine all the correct assemblies you need merged. I wouldn't revommend using this tool, unless you understand how it works.
Note: If you want to use ILMerge with .Net v4.0, read this page.