I am having an awful time understanding how MSBuild works with NET Core project files (csproj) on Windows 11. I have 71 NET Core C# project files (executables, libraries, test projects). They all compile and run properly under Visual Studio or with msbuild batch jobs that build and PUBLISH to a publish folder on the command line.
BUILDING LOCALLY PRODUCES DIFFERENT BIN/* FOLDERS
But when I run MSBuild (with the same command-line arguments) on the 71 projects to build locally (not publish locally), some of the projects produce different output folders.
Some of them create bin/Debug/* folders, some create bin/x64/Debug/ folders, and some projects produce both types of folders. The “*” part is framework/runtime, which is net5.0-windows/win-x64 on my system.
Here is what my typical NET 5.0 project file looks like:
<PropertyGroup>
<Platforms>AnyCPU</Platforms>
<PlatformTarget>AnyCPU</PlatformTarget>
<TargetFramework>net5.0-windows7.0</TargetFramework>
<SelfContained>false</SelfContained>
<IsPackable>false</IsPackable>
<IsPublishable>false</IsPublishable>
// The IsPublishable setting makes no difference.
// The build operation is not a publishable operation.
</PropertyGroup>
Here is what my MSBuild command looks like for all 71 projects
MSBuild /t:Restore;Build /p:Configuration=Debug /p:Platform=x64 /p:RuntimeIdentifier=win-x64 csproj-file-pathname
I have done many experiments, including completely deleting the obj and bin trees before running the MSBuild command lines, but nothing works. I cannot see any discernible relationships among project files, types of projects (lib or exe or app), and MSBuild command line arguments that would explain the different local build output folders.
Does anyone know what would make some projects create different output folder structures (and contents) if the project files are the same and the MSBuild arguments are the same?
Does anyone know for sure exactly what bin/* output folders should be produced by the msbuild arguments shown above? I have spent hours fighting the issue without success. Thank you.
MSBuild Structured Log Viewer is going to be your friend here. Whenever I need to know exactly what MSBuild is doing, I break this tool out.
I made a couple of library projects to show you what's going on
Here's the solution configuration for x64
I build the solution with the same properties you are using.
I'm pretty familiar with MSBuild and I know what property to look for, for the final copy. So I search for $property OutDir. This means I'm looking for an MSBuild property with the name that contains OutDir.
As you can see, we're pretty much getting the same situation you described. Some have bin\x64\Debug while some are just bin\Debug. They all have their target framework appended but they also have their runtime identifier appended.
If we want to see the project exactly as MSBuild sees it. We can expand the evaluation folder and click the "Preprocess" from the context menu. This will be a monster xml. This is actually your csproj in its full expanded glory after all the .props and .targets imported from the .NET SDK and from your repo.
You can get this file from the cli as well with MSBuild -preprocess[:file] option.
There's a lot of stuff going on but really we're only looking for stuff that directs the output. I know OutputPath is used in OutDir so I search for OutputPath and jump around. I find that the special .targets file that controls default outputs is called Microsoft.NET.DefaultOutputPaths.targets. Here's the relevant portion:
<Configuration Condition="'$(Configuration)'==''">Debug</Configuration>
<Platform Condition="'$(Platform)'==''">AnyCPU</Platform>
<PlatformName Condition="'$(PlatformName)' == ''">$(Platform)</PlatformName>
<BaseOutputPath Condition="'$(BaseOutputPath)' == ''">bin\</BaseOutputPath>
<BaseOutputPath Condition="!HasTrailingSlash('$(BaseOutputPath)')">$(BaseOutputPath)\</BaseOutputPath>
<OutputPath Condition="'$(OutputPath)' == '' and '$(PlatformName)' == 'AnyCPU'">$(BaseOutputPath)$(Configuration)\</OutputPath>
<OutputPath Condition="'$(OutputPath)' == '' and '$(PlatformName)' != 'AnyCPU'">$(BaseOutputPath)$(PlatformName)\$(Configuration)\</OutputPath>
<OutputPath Condition="!HasTrailingSlash('$(OutputPath)')">$(OutputPath)\</OutputPath>
The first part of your question can finally be answered. For projects that build under the AnyCPU solution (even when you specify x64), you don't get the $(Platform) in the output. You can see that in my example: only net6lib has x64 in the OutDir.
So what about the runtime identifier, I don't see it in this .targets file. It's actually expanded on a little later in a different file: Microsoft.NET.RuntimeIdentifierInference.targets.
Relevant portion with comment
<!--
Append $(RuntimeIdentifier) directory to output and intermediate paths to prevent bin clashes between
targets.
But do not append the implicit default runtime identifier for .NET Framework apps as that would
append a RID the user never mentioned in the path and do so even in the AnyCPU case.
-->
<PropertyGroup Condition="'$(AppendRuntimeIdentifierToOutputPath)' == 'true' and '$(RuntimeIdentifier)' != '' and '$(_UsingDefaultRuntimeIdentifier)' != 'true'">
<IntermediateOutputPath>$(IntermediateOutputPath)$(RuntimeIdentifier)\</IntermediateOutputPath>
<OutputPath>$(OutputPath)$(RuntimeIdentifier)\</OutputPath>
</PropertyGroup>
And there's the last part of your output portion. $(TargetFramework) gets inserted in there as well between the previous target I mentioned and this target but you already knew that.
There is no madness here at all. MSBuild is following exactly what it's been told to do.
Hopefully this helps some!
I have a visual studio 2010 solution file containing a number of project files. If I clean the solution using devenv then the clean completes successfully, however, if I use MSBuild, two of the project files fail to clean due to a missing dependency, error MSB3395. If I run Clean a second time, immediately after the failure, the clean completes without errors.
Our build using MSBuild succeeds.
Task "UnregisterAssembly" (TaskId:204) ...
...
error MSB3395: Cannot unregister assembly
"C:\Build\Dir\MyFile.dll". Could not load file or
assembly 'MyOtherFile, Version=10.0.0.414,
Culture=neutral, PublicKeyToken=266e457ed35afd03' or one of its
dependencies. The system cannot find the file specified.
[C:\Build\Dir\ProjFolder\MyFileProj.vbproj]
Yes, this assembly is a COM interop assembly and so the build registers the assembly. If I delete the UnmanagedRegistration.cache files associated with the two problem areas then the clean finishes without problems. However, these files are not unregistered and registry fills up with old COM registrations. I am not certain of the impact on future builds either.
I have read the article for VS2008 projects here https://blogs.msdn.microsoft.com/visualstudio/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe/
However, I don't think this applies in this case because this build process has been cleaning and building properly for months.
I have also read: https://www.experts-exchange.com/questions/26259422/msbuild-can't-clean-project-with-C-COM-component-dependant-on-other-NET-library.html. I attempted to clean the two different projects before cleaning the solution affected by this, but this too failed. e.g.,
msbuild ".\ProjDir\MyProj.csproj" /t:clean /p:configuration=Release /fl /flp:logfile=".\..\LogFiles\msbuildClean.log";verbosity=diagnostic
I have tried reverting to a previous SVN revision before the problem began to show but I still get the same error. My build machines are on Virtual Machines, and I even tried reverting the build machine to a snapshot prior to the problem showing up, but still the error would show up.
I have been at this for two weeks now, and my only recourse is to use devenv to clean the solution, which is very slow. My only idea at this time is that when using msbuild that dependencies for COM interfaces are not handled correctly for a clean but I have no idea how to fix the problem.
I can reproduce the problem using the VS2010 CMD Prompt. Below is an example cmd line that I use
msbuild "A Solution.sln" /t:clean /p:Configuration=Release /fl /flp:logfile=".\..\LogFiles\msbuildClean.log";verbosity=diagnostic
msbuild "A Solution.sln" /t:build /p:Configuration=Release /fl /flp:logFile=".\..\LogFiles\msbuildBuild.log";verbosity=diagnostic
Within the vbproj files there are PropertyGroups with a Release configuration condition. All of these include <RegisterForComInterop>true</RegisterForComInterop>. If I set this value to false, then the error goes away because there isn't anything to unregister. However, I need the .tlb files in order to compile our vb6 project.
So, are there any problems for me to just set this to false and then use Regasm to register the assemblies post build, and unregister before a clean? Does anyone have any ideas why MSBuild would suddenly have problems with this process when for months the build has run successfully?
Thanks.
UPDATE
If I use msbuild to clean the first problem project, this clean works
successfully.
The second project however fails to clean properly
When cleaning the first project, ProjA, it also removes dependent
files from other projects, ProjB.
When I clean the second problem project, ProjC, it also has dependencies on ProjB.dll, and this file is missing.
QUESTION
- How do I keep MSBuild from removing files required by other projects?
In the end I have to go with stijn's answer.
I never did find the cause - something in the msbuild clean process seems to delete the files required to unregister an assembly.
I had tried to create a msbuild task to unregister the assemblies first, but that too failed.
In the end I coded a Powershell script that searched a path for *.unmanagedregistration.cache files. I then can determine the .dll file name from the unmanagedregistration.cache file and then once the code runs regasm /unregister, it will remove the file.
Just perform the clean as administrator. If using visual studio, open it as administrator and it should perform the clean action.
So, as the title reads, I have a VS2010 solution with ~50 projects in it right now. If I make a change to a "top level" project that nothing references then VS still rebuilds all 50 projects. I'm running Visual Studio 2010 Ultimate without any add-ons. I am using ILMerge to consolidate all of the projects into a single file.
I have verified this by checking the time stamps of the lower level dlls and see that they are indeed rebuilt even though their code wasn't touched.
I've read all responses and comments for:
Visual Studio 2008 keeps rebuilding
Visual studio keeps building everything
Strange VS2010 build glitch occurs in my solution
Reasons for C# projects to rebuild in Visual Studio
But most of them just offer suggestions on unloading projects to speed up build times but nothing concrete as to a fix. I'm trying to figure out why VS thinks these dependent projects need to be rebuilt when they don't and fix it.
I've turned on 'Tools > Options > Projects and Solutions > Build and Run > Only build startup projects and dependencies on run' but with no effect.
Also, if I just rebuild a "mid-level" project that only has 8 (in)direct dependencies then it still builds all 8 projects even though ILMerge isn't invoked and none of the dependent projects have been modified.
Thank you everyone for any insight you may be able to provide.
Added
To test some of the suggestions I created a new WinForms project from scratch. I then created two new projects inside that solution. I copied all of the code and resources (not project file) from my two 'lowest level' projects into the two brand new projects (I did this by dropping the files and folders from Explorer onto the project in Visual Studio).
The lowest project, let's call it B, did not reference any other project. The next project, A, referenced B only. So once I added the required .NET and external assembly references to the projects then the solution would build.
I then had my new WinForm project reference A and did a full build. So the ref chain is:
WinForm -> A -> B
I then modified WinForm only and did a standard build (F6). As before, Visual Studio rebuilt all three projects.
After some systematic eleminiation of source files in project B I found that if I removed my Resources.Designer.cs and Resources.resx (and commented out the code that made use of the .Properties.Resources object of those resources) then a modification of WinForm would no longer rebuild the entire solution and would only rebuild WinForm.
Adding the Resources.resx and Resources.Designer.cs back to project B (but leaving the referenced code commented out so that nothing was making use of the resources) would re-introduce the full build behavior.
To see if perhaps my resource files were corrupted, I deleted them again and then created a new one (via Project Properties -> Resources) and re-added the same resource as before, which was a single Excel file. With this setup the full rebuild would still occur.
I then removed the single resource, but left the resource file in project B. Even with no resources added, but the resource file still in the project, the full (unneeded) rebuild would occur.
It appears that just having a resource file added to a (.NET 3.5) project will cause Visual Studio 2010 to always rebuild that project. Is this a bug or intended/expected behavior?
Thanks all again!
Open Tools - Options, select Projects and Solutions - Build and Run in tree, then set "MSBuild project build output verbosity" to Diagnostic.
This will output the reason for building a project, i.e.
Project 'ReferencedProject' is not up to date. Project item
'c:\some.xml' has 'Copy to Output Directory' attribute set to 'Copy
always'.
or
Project 'MyProject' is not up to date. Input file
'c:\ReferencedProject.dll' is modified after output file
'c:\MyProject.pdb'.
In this case the fix is to copy some.xml only if newer.
Pre and post build events can trigger build as well.
While I don't think this is a fix, it is a workaround that has worked for my situation...
I originally had about 5 projects out of 50 that contained a Resources section. These projects would always be rebuilt and thus anything that they depended on would also be rebuilt. One of those 5 projects was a "base" level library that 48 of the other projects referenced, thus 96% of my project would be rebuilt every time even if it didn't need it.
My workaround was to use dependency injection, interfaces, and a dedicated "Resources" project. Instead of having those 5 projects reference their own Resources object, I created an interface in each project that would supply the desired resources. Then, the classes that needed those resources would require that interface be passed in during their creation in the constructor (constructor injection).
I then created a separate "Resources" project that had an actual Resources section like normal. This project only contained the resources themselves, and a class for each interface that was needed to provide those resources via an interface. This project would reference every other project that had a resource dependency and implement the interface that the project needed.
Finally, in my "Top Level" project which nothing referenced (and where the exe was actually built and my composition root lives) I referenced the "Resources" project, wired up the DI, and away we went.
This means that only two projects (the "Resources" and the "Top Level") will be rebuilt every time, and if I do a partial build (Shift-F6) then they won't get rebuilt at all.
Again, not a great work around, but with 48 projects being built every time a build would take about 3 minutes, so I was losing 30 to 90 minutes a day with needless rebuilds. It took awhile to refactor, but I think it was a good investment.
Here is a simplified diagram. Note that the dependencies from Main.exe to Proj1 and Proj2 are not shown in order to reduce clutter.
With this design, I can do a build of Proj1 or Proj2 without triggering a full rebuild, since they don't have any dependencies on a Resources section. Only Main knows about the Resources implementation.
This happens when a project has a file that doesn't really exist.
The project can't determine if the file was changed (because it's not there) so it rebuilds.
Simply look at all the files in the project, and search for the one that doesn't have an expandable arrow near it.
I had the same issue in VS 2015.
What did the trick for me is:
One project was referencing itself copy in some other project bin (magic, yes). This kind of stuff could be found when switching to diagnostic build output (in build options) and then trying to build projects one by one from the top of projects hierarchy - if you see the project that rebuilds even if nothing has been changed then see it's references.
I've changed all "copy always" files in all projects to "copy if newer". Basically, in all .csproj files replace <CopyToOutputDirectory>Always</CopyToOutputDirectory>
to <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
Then I've disabled NTFS tunneling as described in this article with this powershell script:
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "MaximumTunnelEntries" -Value 0 -PropertyType "DWord"
After that I needed on rebuild and it seems working for now.
In my case the culprit was "Copy Local" setting of a referenced dll set to true and "Copy to Output Directory" setting a file set to Copy always.
For .Net Core Projects, all solutions above are not working.
I've found the solution. In case you are using Visual Studio 2019:
Build the solution twice
Turn on Tools -> Options -> Projects and Solutions -> SDK-Style Projects -> Logging Level -> Verbose
Clear the output window
Build your start project
Inspect the output window. All the string starting with FastUpToDate
You will find some project items that are making your project not up to date.
Fix these issues and try again from step 1. If your fixes are correct, you will achieve Build: 0 succeeded, 0 failed, {n} up-to-date, 0 skipped in the last string of build output.
The MSBuild team is collecting documentation about investigating build incrementality issues here:
https://github.com/Microsoft/MSBuild/wiki/Rebuilding%20when%20nothing%20changed
UPDATED LINK: https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Rebuilding-when-nothing-changed.md
Based on your observations, it sounds like you have projects expressing dependencies to other projects in a way that isn't obvious. It is possible for orphaned dependencies to remain in project files without being apparent in the UI. Have you looked through a misbehaving project file after opening it in a text editor? Checked solution build dependencies?
If you're not able to spot anything, try recreating one of your projects from scratch to see if the new project exhibits the same problem. If the clean project builds correctly, you'll know that you have unwanted dependencies expressed somewhere. As far as I know, these would have to be in the project file(s) or the solution file, unless you have makefiles or other unusual build steps.
Another problem that frequently happens is when some item in your solution has a modified stamp that is in the future. This can happen if you set your clock forward, and then set your clock to the correct time. I had this happen while installing Linux.
In this case you can recursively touch all the files using git bash (yes, in Windows):
find . -exec touch {} \;
I've finally found one more culprit that I had hard time finding by increasing the build log verbosity.
In some cases, MSBuild looks for vc120.pdb in the output folder, and if this file doesn't exist, it will rebuild the entire project. This occurs even if you have disabled debug symbol generation.
The workaround here is to enable debug symbols and let this file get generated, then disable the setting again without deleting the PDB file.
I had this same problem and it turned out to be related to a couple of project that had a copy local reference to a dll in their own output directory.
The key to finding this was having diagnostic output set for the build output, but also knowing what to look for in the log. Searching for: 'not up to date' was the key.
Here is an answer from VS2010 always rebuilds solution?
This issue is solved by changing the project files, cleaning solution,
deleting all bin folders by hand, restarting Visual studio and
rebuilding everything.
I had the same issues with you.
I found that it came from some deleted files.
When I had removed the files from my project, the issues was gone.
Regards.
For this category of build problems setting MSBuild output verbosity to 'diagnostic' is indeed a necessary first step. Most of the time the stated reason for the re-builds would be enough to act upon, BUT occasionally MSBuild would erroneously claim that some files are modified and need to be copied.
If that is the case, you'd need to either disable NTFS tunneling or duplicate your output folder to a new location. Here it is in more words.
I had the problem of Visual Studio rebuilding projects when upgrading from Visual Studio 2015 to 2017 and I add this answer for the benefit of those who might experience similar problems, as it does not seem to be documented anywhere.
In my case, the problem was that all projects in the solution had the same intermediate Output path (obj). The file GeneratedInternalTypeHelper.cs gets generated by all projects containing XAML. Up to Visual Studio 2015, the build process apparently did not check for the file date of this file and thus no problem with it occurred. With VS2017 the file date of this file is checked and because a later project in the build process will overwrite it (with the same content), the earlier project will re-build, re-triggering the later build, ad infinitum.
The solution in this case is to ensure that all projects have differing intermediate output directories, which will make the problem go away.
In my case (mixed C#, C++/CLI and native C++ solution) , some C++ projects were being re-linked even if nothing had changed. I spent ages trying to work out what was happening. In the end I worked out from the "Command Line" option that the PDB output path (option /Fd) could not handle the folder setting $(IntDir). I removed that - an empty value will do the default correctly - and my issue went away.
As others have noticed, a likely reason is that CopyToOutputDirectory is set to Always. This can be fixed simultaneously in all project files by applying the powershell script below:
$folder = "C:\My\Solution\Folder"
$csvFiles = Get-ChildItem $folder *.csproj -rec
foreach ($file in $csvFiles)
{
(Get-Content $file.PSPath -Encoding UTF8 -Raw) |
Foreach-Object { $_ -replace "<CopyToOutputDirectory>Always</CopyToOutputDirectory>", "<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>" } |
Set-Content $file.PSPath -Encoding UTF8 -NoNewline
}
Files that do not exist are a problem and obviously files producing no output as well. That can happen, wenn you have a resource file in a static library. (C++)
I have two applications developed in VS2010 (C#, .NET 4.0) - each is a separate solution with 2 projects, one for the app-specific elements, plus the project for a shared library which builds a DLL.
My problem is when this DLL is built, under one of the builds the DLL is 16384 bytes (0x4000) larger than it should be. This size difference is the same for both Debug and Release builds. WHile the proper version is within ClearCase, I get exactly the same result with a copy on the C: drive, so it doesn't seem to be a config-spec or view-related issue.
I've trawled through the VS settings, completely removed the bin/obj folders to force a complete rebuild, used WinMerge to diff all the files/folders, all with no success.
Using dumpbin, I can see in the clr header a 0x3F20 size difference for the Resources Directory. I suspect the remaining 0xE0 is attributable to section alignment within the DLL.
At this point I'm stumped. Any suggestions on what could be causing this or what steps to investigate further???
EDIT:
Maybe I didn't describe the VS solution very well - The solution has 2 projects. The shared library is simply added to the solution via Add->Existing Project. Both projects are then built when selecting Build->Rebuild Solution.
Re. Hans' comment, it's a problem from a configuration management/confidence standpoint. If no source code/project files have changed, the only thing I'd expect to change in the DLL is any build time/version details - not a 15K delta like I have.
The problem was in the .suo (Solution User Options) file, which must have been corrupted (and unfortunately placed and maintained under version control by previous users). Thankfully it appears nothing significant is lost by the removal of this file.
A little more info on .suo files can be found in the SO question Why are there sln, suo and csproj files?
A quote from Debugger Settings Visual Studio Add In– Easily Copy Breakpoints between Machines sums it up well:
The .SUO file is the bane of your existence. Nearly all the problems you encounter with Visual Studio are the result of a corrupt .SUO file. Sadly, it seems all it takes to corrupt the .SUO file is your heart beating. In other words, whenever you have Visual Studio crash, refuse to debug, or behave strangely it's the .SUO file's fault. Whenever anyone asks me about strange Visual Studio behavior, my instantaneous response is "Delete the .SUO!" When it comes to Visual Studio hygiene, deleting the .SUO file is right up there with cancer screenings.
Hereis the situation:
I have a folder that contains library DLLs, which are not built as part of my solution - lets say it is .\libs.
I add references to these DLLs. I then build. Everything is fine.
If I then delete the libs folder and rebuild my solution, the compilation still succeeds! Weird - I would have expected compilation errors since the library dlls are not there!
But looking at the reference properties in Visual studio, I see that the reference path has been changed from .\libs\foo.dll to myproject\bin\Debug\foo.dll. So it is picking up the referenced DLL from its old build output.
If I open myproject.csproj in a text editor, I see that the HintPath of the reference is still .\libs\foo.dll. If I re-create the libs folder, visual studio still uses myproject\bin\Debug\foo.dll (it does not revert to the actual DLL I want!)
Is this expected behaviour?
Is there a way to stop this behaviour because it is causing me problems - especially when I want to rebuild myproject with different versions of the libs: half the time I find that I am using a different version than what I wanted.
This is not magic. Your DLL's Copy Local Property is probably set to true, that's all.
Setting it to false will get you the desired behaviour.