After some changes to my project, Visual Studio started to always re-compiles all sources, causing all dependent project to also re-compile, slowing down development considerably. Why is that?
Happens only when XML documentation file is checked and there's some file with Copy always. If you change either of these, the sources don't get re-compiled.
Happens only when compiling inside Visual Studio - when compiling using MSBuild from commandline, the sources don't get re-compiled.
Visual Studio 2012 Update 4.
This appears to be a bug in Visual Studio, when project has XML documentation file checked some files with Copy always.
Repro:
Create new project - C# class library.
Project Properties => Build => check XML documentation file
Project => Add => New Item => Text file TextFile1.txt
Change TextFile1.txt Copy to Output Directory to Copy always
Right-click project => build
project compiles
Right-click project => build
Expected: Project shouldn't be built, build output should say:
========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
Actual: Project is build, output is:
------ Build started: Project: ClassLibrary1, Configuration: Debug Any CPU ------
ClassLibrary1 -> bin\Debug\ClassLibrary1.dll
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Intestigation: Turning on detailed log, you see:
Target "CoreCompile" in file "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.CSharp.targets" from project "ClassLibrary1.csproj" (target "Compile" depends on it):
Building target "CoreCompile" completely.
Output file "bin\Debug\ClassLibrary1.XML" does not exist.
Looking in procmon, you see that devenv.exe renames "ClassLibrary1.XML" into "vsA381.tmp" just before MSBuild.exe runs. Stack trace for the rename:
KERNEL32!MoveFileW+0x17
csproj!CMoveOutOfTheWayScope::EnterScope+0x85
csproj!CVsProjBuildableProjectCfg::StartBuildProcessWithTarget+0x50b
csproj!CVsProjBuildableProjectCfg::StartBuildProcess+0xc
csproj!CVsProjBuildableProjectCfg::StartBuildEx+0x15
msenv!CSUIBuilder::DoBuild+0x1a3
msenv!CSUIBuilder::Run+0x66
Related
I've just updated my VS to ver. 16.8.3 and now suddenly I am getting this error:
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1720,5): error :
Internal MSBuild error: Non-CrossTargeting GetTargetFrameworks target should not be used in cross targeting (outer) build
Not sure at all what to do about this.
We have been working on this project for years and never had such an issue.
Any thoughts?
Seems that the problem is with projects that use multiple .net frameworks AND they referenence ANOTHER project that uses multiple .net frameworks
I have a MINIMAL sample solution at: my public drive
The solution contains two minimal/empty projects that are technically the same except that the one named Microdesk.DbApp referencing the one name Microdesk.Infrastructure.
The Infrastructure project compiles fine while the DbApp project throws the above error.
This solution was working fine for us for multiple years and broke with the latest VS release 16.8.3
Okay, partially my bad.
I did re-compile the EMPTY sample project and found that despite the compiler error, the solution does build.
1>------ Rebuild All started: Project: Microdesk.BIMrxCommon.Infrastructure, Configuration: Debug2020 Any CPU ------
1> Microdesk.BIMrxCommon.Infrastructure -> C:\Work\Microdesk.BIMrx\bin\Debug2020\Microdesk.BIMrxCommon.Infrastructure.dll
2>------ Rebuild All started: Project: Microdesk.BIMrxCommon.DbApp, Configuration: Debug2020 Any CPU ------
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1720,5): error : Internal MSBuild error: Non-CrossTargeting GetTargetFrameworks target should not be used in cross targeting (outer) build
2> Microdesk.BIMrxCommon.DbApp -> C:\Work\Microdesk.BIMrx\bin\Debug2020\Microdesk.BIMrxCommon.DbApp.dll
========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========
BUT if you try to USE anything from the Infrastructure project in the referencing DbApp project then the Solution will NOT compile
Rebuild started...
1>------ Rebuild All started: Project: Microdesk.BIMrxCommon.Infrastructure, Configuration: Debug2020 Any CPU ------
2>------ Rebuild All started: Project: Microdesk.BIMrxCommon.DbApp, Configuration: Debug2020 Any CPU ------
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1720,5): error : Internal MSBuild error: Non-CrossTargeting GetTargetFrameworks target should not be used in cross targeting (outer) build
2>C:\Work\Microdesk.BIMrx\BIMrxCommon\Microdesk.BIMrxCommon.DbApp\DerivedClass.cs(1,29,1,4
): error CS0234: The type or namespace name 'Infrastructure' does not exist in the namespace 'Microdesk.BIMrxCommon' (are you missing an assembly reference?)
2>C:\Work\Microdesk.BIMrx\BIMrxCommon\Microdesk.BIMrxCommon.DbApp\DerivedClass.cs(5,33,5,42): error CS0246: The type or namespace name 'BaseClass' could not be found (are you missing a using directive or an assembly reference?)
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========
I did upload a second sample project named "Microdesk.BIMrx (2).zip" to the previous OneDrive directory
When I test your issue in your side, I did not face the same behaviors as you described. So I guess that there is some issues on your current vs environment due to the update. And maybe the update broke some tools of VS.
So please try the following steps to troubleshoot it:
Suggestions
1) disable any third party installed extensions under Extensions-->Manage Extensions-->Installed
2) close VS, delete .vs hidden folder, every bin and obj folder of your project.
and also delete all cache files under C:\Users\xxx(current user)\AppData\Local\Microsoft\VisualStudio\16.0_xxx\ComponentModelCache
Then, restart VS to test again.
3) or create a new project and then migrate the content from the old into the new one to test whether the issue is related to your VS or the special project itself.
4) If this does not work, do an initialization operation on your VS.
Close VS, delete the whole user folder under C:\Users\xxx(current user)\AppData\Local\Microsoft\VisualStudio\16.0_xxx and then restart VS to test again.
5) repair vs from the vs_installer
I'd like to use a script to build translations (convert from .ts to .qm, using Qt's lrelease.exe) before compiling the resource file (QRC) where they are included. In this way I know they are always updated, not to mention to avoid including binary files in the repository.
I use Visual Studio and have installed the Qt Visual Studio Tools. Normally, I'd do this through a pre-build step in the project, but it is not being executed and the compilation of the QRC file always fails.
1>------ Build started: Project: MyApp, Configuration: Release Win32 ------
1>Rcc'ing MyApp.qrc...
1> RCC: Error in 'C:\src\MyApp\MyApp\MyApp.qrc': Cannot find file 'translations/myapp_en.qm'
1>MyApp.qrc : error 1: rcc (c:\Qt\qt_5_12_3\v141\Win32\bin\rcc.exe)
1>Done building project "MyApp.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 12 up-to-date, 1 skipped ==========
The script works correctly and it is called successfully either if placed as a post-build event or from command line.
#echo off
pushd "%1"
for %%F in (*.ts) do (
c:\Qt\qt_5_12_3\v141\Win32\bin\lrelease -compress %%F -qm %%~nF.qm
)
popd
exit /b 0
What I'm I doing wrong?
It happened that I was using the new Qt/MSBuild mode of Qt VS Tools. Internally it generates several hidden targets in the MSBuild workflow, which are executed before the pre-build events.
The solution was to use a custom build step instead, with some specific settings:
Execute before the QtRcc target (the one that actually compiles the resource file)
The Qt VS Tools parses QRC files to check if the resources have been modified, so it can skip compiling them. It is necessary to add the .qm translation files as output of the custom build step.
Similarly, to guarantee translations are always compiled, set dependencies of the custom build step to the .ts source files.
I've looked at more pages than I can count about how to solve the "I didn't change anything, so why is VS rebuilding my project" problem. And they were helpful for resolving a number of issues with "copy always" flags, and custom build steps that always run. But I'm left with one that won't go away. It passes all the up-to-date fast dependency checks, but continues to start the build anyway. I've traced through all the MSBuild output at the diagnostic level, but I think the "normal" (not minimal) level is sufficient to point in the right direction. Here's the output:
1>------ Build started: Project: OnePawDataSerializer, Configuration: Debug x64 ------
1>Build started 12/20/2019 5:04:37 PM.
1>GenerateTargetFrameworkMonikerAttribute:
1>Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files.
1>CoreCompile:
1>Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
1>_CopyFilesMarkedCopyLocal:
1> Touching "D:\Volpe\NuCS-HiEx\NuCS-Repo\Applications\FAB4DA\OnePawDataSerializer\obj\x64\Debug\OnePawDataSerializer.csproj.CopyComplete".
1>_CopyAppConfigFile:
1>Skipping target "_CopyAppConfigFile" because all output files are up-to-date with respect to the input files.
1>CopyFilesToOutputDirectory:
1> OnePawDataSerializer-> D:\Volpe\NuCS-HiEx\NuCS-Repo\Applications\FAB4DA\bin\Debug64\OnePawDataSerializer.exe
1>
1>Build succeeded.
1> 0 Warning(s)
1> 0 Error(s)
1>
1>Time Elapsed 00:00:00.20
========== Build: 1 succeeded, 0 failed, 15 up-to-date, 0 skipped ==========
At this level of output verbosity it doesn't show all the stuff that looks like this:
1>------ Up-To-Date check: Project: CommonDataModelUtilities, Configuration: Debug x64 ------
1>All outputs are up-to-date.
1>Time Elapsed 19 ms
But they all indicate that everything is up to date. In the "normal"-level output, it shows a couple of internal targets being skipped, but then seems to need to execute one called "_CopyFilesMarkedCopyLocal", which doesn't seem to actually copy anything, but does appear to create a file with the name of the project file appended by ".CopyComplete". This appears to be the only instance of the build actually "doing" something tangible, so I'm inclined to suspect that this has something to do with why I'm not seeing this:
========== Build: 0 succeeded, 0 failed, 16 up-to-date, 0 skipped ==========
when I build. But I can't figure out why it's doing it. Any thoughts?
This appears to be the only instance of the build actually "doing"
something tangible, so I'm inclined to suspect that this has something
to do with why I'm not seeing this: ========== Build: 0 succeeded, 0
failed, 16 up-to-date, 0 skipped ========== when I build. But I can't
figure out why it's doing it. Any thoughts?
MSBuild uses incremental compilation, which only compiles files that have been modified, and skips building for files that have not changed. So when build your project again without any changes, it will like this as you wish:
========== Build: 0 succeeded, 0 failed, 16 up-to-date, 0 skipped ==========
This is the normal behavior generated by MSBuild.
But if you build your project again without changing any project files and build always execute, l am afraid that the issue is caused by some project files' settings(set Copy to Output Directory to Copy Always). (Or you can see the files in the xxx.csproj file and then you will find some files add the node <CopyToOutputDirectory>Always</CopyToOutputDirectory>)
According to the build log info from your picture, the targets _CopyFilesMarkedCopyLocal and CopyFilesToOutputDirectory are responsible for copying project resources which you specify as the picture shows to the output path. And when you set the file to Copy Always, MSBuild will always consider this operation to be up to date, so it will always execute.
Note: Build is the process by which msbuild executes a bunch of target targets which contains the compile target. If the files are already compiled and they are not changed, the target will skip. Besides, if some projects are not changed, MSBuild will skip compiling them and regard them as up - to - date.
To prove it l have do a test:
1) I set the project file called JavaScript1.js to Copy Always as the picture shows above.
2) Then when I build the project multiple times, it always turns that the build executes successfully.
In addition, if you want this behavior, you could set Copy to Output Directory to Do not copy. Or if you want to output these files, you can set to Copy if newer.
Update1
If cannot see this abnormal behavior directly, l think you can set MSBuild project build output verbosity to Diagnostic.This mode will display every detailed info about build process.
And l have observed that the build log only shows two targets which are
running _CopyFilesMarkedCopyLocal and CopyFilesToOutputDirectory.
So please check the target CopyFilesToOutputDirectory, _CopyFilesMarkedCopyLocal, Copy task in the Diagnostic build log by the search box and you can search any detailed info about this.
And in my side, l can see this info in the first line of build output which is explain why my project always rebuild:
Project 'ConsoleApp1' is not up to date. Project item 'C:\Users\Admin\source\repos\ConsoleApp32\ConsoleApp32\JavaScript1.js' has 'Copy to Output Directory' attribute set to 'Copy always'.
Hope it could help you.
I am attempting to upload my UWP to the windows store. To do so, I am trying to create an App Package. I am following the steps described on the Microsoft Docs webpage (https://learn.microsoft.com/en-us/windows/uwp/packaging/packaging-uwp-apps), but failing when I try to create the app package. The error I'm getting is:
1>------ Build started: Project: IrishRailTimetables, Configuration: Release x86 ------
1> IrishRailTimetables -> C:\Users\c-raf\OneDrive\Documents\College Work\Year_3\Mobile App\IrishRailTimetables\IrishRailTimetables\bin\x86\Release\IrishRailTimetables.exe
1>LOGGERBASEDEXECTASK : ILC error ILC1104: The directory is not empty.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Deploy: 0 succeeded, 0 failed, 0 skipped ==========
I have no idea what I'm doing wrong. Any help would be greatly appreciated.
Some times visual studio process existing or previous debugging files ,so next time when you debug existing files is not updated with new changes or unknown to new changes.
**Error - Old debugging Files not updated with changes.
so you need to follow these steps-
1) Goto Build > Clean Solution and Close vs.
2) Empty "bin" , "obj" folder of project.
3) You Should also view in taskmanager for any running process of .vs and close it.
4) Then Reopen Your Project and Build it.
I've added an unamanaged dll in project OldTesters using Add Existing File.
I've also set BuildAction = Content and Copy to Output Directory = Copy if newer.
I'm using some functions from unmanaged dll in OldTesters project via [DllImport("unamanged.dll")]
OldTesters is .NET project that I've referenced in my main project using Add Reference.
The problem is when I rebuild application everything works fine, but then I close app,
and then click on start, it throws me DllNotFoundException
Unable to load DLL 'unmanaged.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
I've noticed that Visual Studio deleted unmanaged.dll from bin directory.
If I rebuild OldTesters project then it will work. But it is annoying always to rebuild OldTesters, cause I do not add any changes in that project. To prove that, if I click on Build, I will get:
========== Build: 0 succeeded, 0 failed, 6 up-to-date, 0 skipped ==========
because there are no changes in the project.When I run the app I get the same exception.
Although this is VERY old, I just stumbled across the same problem and found the following solution:
just copy all the dlls that are "deleted" to your current project in VS, then they are copied whenever this project is created.
So in your case you just open the project OldTesters, click on the unmanaged dll, copy and then paste it into the project that your other project.