When building using Visual Studio 2022, targeting net7.0, net6.0, and netstandard2.0, the build fails with the following warnings in the build output (I don't think multi-targeting has any impact):
>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(3588,5): warning MSB3491: Could not write lines to file "obj\Debug\net6.0\.NETCoreApp,Version=v6.0.AssemblyAttributes.cs". Access to the path 'D:\src\XXX\obj\Debug\net6.0\.NETCoreApp,Version=v6.0.AssemblyAttributes.cs' is denied.
>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(3588,5): warning MSB3491: Could not write lines to file "obj\Debug\net7.0\.NETCoreApp,Version=v7.0.AssemblyAttributes.cs". Access to the path 'D:\src\XXX\obj\Debug\net7.0\.NETCoreApp,Version=v7.0.AssemblyAttributes.cs' is denied.
>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(3588,5): warning MSB3491: Could not write lines to file "obj\Debug\netstandard2.0\.NETStandard,Version=v2.0.AssemblyAttributes.cs". Access to the path 'D:\src\XXXn\obj\Debug\netstandard2.0\.NETStandard,Version=v2.0.AssemblyAttributes.cs' is denied.
When logs are set to verbose, the following is emitted (only including for net7.0 TFM):
> Target GenerateTargetFrameworkMonikerAttribute:
> Building target "GenerateTargetFrameworkMonikerAttribute" completely.
> Input file "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.targets" is newer than output file "obj\Debug\net7.0\.NETCoreApp,Version=v7.0.AssemblyAttributes.cs".
> Task "WriteLinesToFile"
> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(3588,5): warning MSB3491: Could not write lines to file "obj\Debug\net7.0\.NETCoreApp,Version=v7.0.AssemblyAttributes.cs". Access to the path 'D:\src\XXX\obj\Debug\net7.0\.NETCoreApp,Version=v7.0.AssemblyAttributes.cs' is denied.
> The previous error was converted to a warning because the task was called with ContinueOnError=true.
> Build continuing because "ContinueOnError" on the task "WriteLinesToFile" is set to "true".
> Done executing task "WriteLinesToFile" -- FAILED.
> Done building target "GenerateTargetFrameworkMonikerAttribute" in project "HatTrick.DbEx.CodeTemplating.csproj".
The warnings reference temporary files created by the build process prior to compilation.
Things I've tried to figure this out:
If I run dotnet build from the command line, it results in the same.
If I change branches/pull or clean/build/rebuild, the build fails - there are no error messages in the output, only the warnings above.
If I restart Visual Studio and rebuild, the build succeeds, but still has the warnings.
I've tried on another machine and it works as expected (no errors or warnings) - I cannot reproduce this issue on another machine.
I don't think it's a file/directory permission exception because I can rebuild and the build process outputs the assemblies to the bin and obj folders just fine.
Related
I am trying to compile an android app with XF. I am getting the infamous java.exe exited with code 1 error message. I have enabled proguard.
I have gotten the error just from enabling proguard.
The error only seems to happen in VS for Windows. I got a different error in VSMac, but don't have that right here in front of me.
Updating proguard from it's home on sourceforge doesn't seem to do anything for me.
I have put a new proguard.cfg file in my project and have set the build property to be a proguard configuration file.
I don't know what to do here. I'm looking for any suggestions.
TIA.
Update 1:
I didn't add the build output because I couldn't find a good exception in it. I just have the following that I can find in the build output.
I wish I could find the error easily. I had turned on the build output. the only exception i can find is listed below. I checked the targets file and the line reference is for the Proguard section.
1> at proguard.Initializer.execute(Initializer.java:485)
1> at proguard.ProGuard.initialize(ProGuard.java:271)
1> at proguard.ProGuard.execute(ProGuard.java:113)
1> at proguard.ProGuard.main(ProGuard.java:572)
1> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2550,3):
Link to build output: https://www.dropbox.com/s/jl1o2hf7aeji243/BuildOutput.zip?dl=0
Suddenly I cannot rebuild my project in VS 2017. I get these messages:
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(4222,5): error MSB3021: Unable to copy file "C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp\.NETFramework\v4.0\4.4.1.0\FSharp.Core.dll" to "bin\Debug\FSharp.Core.dll". Access to the path 'bin\Debug\FSharp.Core.dll' is denied.
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(4222,5): error MSB3021: Unable to copy file "H:\Dropbox\BitBucket\VSProjects\Fractal10\packages\Newtonsoft.Json.9.0.1\lib\net45\Newtonsoft.Json.dll" to "bin\Debug\Newtonsoft.Json.dll". Access to the path 'bin\Debug\Newtonsoft.Json.dll' is denied.
Any suggestions on how to solve this problem?
Possible causes:
The app you are trying to build/debug can be running or stuck open
Tests locking the assemblies could be using them
post-build steps listed in the properties page of a project could be using them
while building multiple projects in parallel: another project could have decided to use those dll in the output folder for those references
Visual Studio's F# interactive if set to not shadow copy assemblies could cause it.
anything else that causes a file to be locked in windows
It happened today for me, I had pulled a branch from git repo and the project was not getting compiled or cleaned.
I had to uncheck read-only option for the root directory and the nested files & folders of the root directory.
Go to the folder where the project is, right click on the directory, click properties, Uncheck Read-only option.
Since VS2010, Microsoft Visual Studio introduces the Platform Toolset concept that encapsulate the traditional global INCLUDE, LIB, PATH settings inside various Toolsets. I admit that's an improvement for flexibility, but it should not be a blackbox that makes us foolish.
Now my question is, how do I know what the resulting INCLUDE, LIB, PATH are when I apply a Toolset to my project. I think it is not realistic to analyze those hundreds of .targets and .props files(in C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120) manually to get the result. Most of the time, we just need the result. Is there any concise way to achieve that?
==== UPDATE ====
Stijn provides the right answer for me. Now I can see PATH= , LIB= , INCLUDE= ... from the build log. But, a minor question, what is the difference of LIB and LIBPATH?
1>Using "SetEnv" task from assembly "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.Build.CppTasks.Common.dll".
1>Task "SetEnv"
1> PATH=C:\VS2013\VC\bin;;C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools;C:\VS2013\Common7\Tools\bin;C:\VS2013\Common7\tools;C:\VS2013\Common7\ide;C:\Program Files (x86)\HTML Help Workshop;;C:\Program Files (x86)\MSBuild\12.0\bin\;C:\Windows\Microsoft.NET\Framework\v4.0.30319\;C:\Windows\SysWow64;;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;;C:\Windows-Kits\8.1\bin\x86;C:\Windows-Kits\8.1\tools\tracing\x86
1>Done executing task "SetEnv".
1>Task "SetEnv"
1> LIB=C:\VS2013\VC\lib;C:\VS2013\VC\atlmfc\lib;;
1>Done executing task "SetEnv".
1>Task "SetEnv"
1> LIBPATH=C:\VS2013\VC\atlmfc\lib;C:\VS2013\VC\lib;
1>Done executing task "SetEnv".
1>Task "SetEnv"
1> INCLUDE=D:\u8vc\USBview\C++\;C:\VS2013\VC\include;C:\VS2013\VC\atlmfc\include;;
The easisest way is probably to adjust the msbuild log settings so the INCLUDE/LIB/PATH environment variables are printed to the output window. In Visual Studio's options you can either:
set Projects and Solutions->VC++ Project Settings->Show Envirohnment In Log to Yes
set Projects and Solutions->Build and Run->MSBuild project build output verbosity to Detailed or Diagnostic
Then in the build log grep for INCLUDE etc
For command line builds use the /v:d switch with MSBuild.
Here at my new work, we are forced to use Microsoft Team Foundation Server 2008, for our builds.
Even most of developers already moved to VS 2010, and 2012, but the build server is still TFS 2008.
Any way, I am working with VS 2010 project, and I built the "default build definition", on 2008 TFS server.
The build is failing.
Looking at the log, it is trying to delete the workspace "agentserver_104_" but didn't find it, but then later try to create the workspace "agentserver_104_". but it fails because there is already a workspace called "agentserver_104".
This is the error message with the log
Target "CoreInitializeWorkspace" in file "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets"
Using "DeleteWorkspaceTask" task from assembly "c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.Build.Tasks.VersionControl.dll".
Task "DeleteWorkspaceTask"
DeleteWorkspaceTask TeamFoundationServerUrl="http://xxxxx:8080/" BuildUri="vstfs:///Build/Build/21924" Name="agentserver_104_" DeleteLocalItems=True
TF14061: The workspace agentserver_104_;TCPL\TFSBuild does not exist.
Done executing task "DeleteWorkspaceTask".
Task "DeleteWorkspaceTask" skipped, due to false condition;
Using "CreateWorkspaceTask" task from assembly "c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.Build.Tasks.VersionControl.dll".
Task "CreateWorkspaceTask"
CreateWorkspaceTask TeamFoundationServerUrl="http://xxxxx:8080/" BuildUri="vstfs:///Build/Build/21924" Name="agentserver_104_"
BuildDirectory="E:\TFSBuild\Geofind Modernization\GeoFacility 10.1 - Win7" SourcesDirectory="E:\TFSBuild\Geofind Modernization\GeoFacility 10.1 - Win7\Sources" Comment="Workspace created by Team Build"
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(801,5,801,5): error : The path E:\TFSBuild\Geofind Modernization\GeoFacility 10.1 - Win7\Sources is already mapped in workspace agentserver_104.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(801,5): error MSB4018: The "CreateWorkspaceTask" task failed unexpectedly.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(801,5): error MSB4018: Microsoft.TeamFoundation.VersionControl.Client.MappingConflictException: The path E:\TFSBuild\Geofind Modernization\GeoFacility 10.1 - Win7\Sources is already mapped in workspace DAPP03085_104.
Notice that when it tried to delete the workspace, it uses the name agentserver_104_
But the existing name was : agentserver_104
Without the trailing underbar.
any idea?
There seems to be a problem with probably referenced projects i suppose. Because the real error is The path E:\TFSBuild\Geofind Modernization\GeoFacility 10.1 - Win7\Sources is already mapped in workspace DAPP03085_104. So I think you need to check that one.
Building a basic C++ project with Visual Studio 2012. When I make changes to source files:
the corresponding object files are compiled
the .tlog files for the compiler are updated
the PDB file is updated
the .tlog files for the linker however are not changed
the linker claims All outputs are up-to-date. and does not build a new executable.
The only way to get the executable to be built is deleting it. It seems something with the tracking system is wrong and I was wondering if anyone can shed some light on this issue.
Here is the msbuild output after I change two files, full paths and some other stuff omitted (this output is for the VS2010 toolset, but 2012 behaves the same):
1>Target "ClCompile" in file "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.targets"...
Using "CL" task from assembly "Microsoft.Build.CppTasks.Win32, Version=4.0.0.0...
Task "CL"
Read Tracking Logs:
cl.read.1.tlog
CL.2520.read.1.tlog
...
Outputs for ....
XXX.OBJ
YYY.OBJ
...
xxx.cpp will be compiled as xxx.cpp was modified...
yyy.cpp will be compiled as yyy.cpp was modified...
Write Tracking Logs:
cl.write.1.tlog
CL.2520.write.1.tlog
...
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe ....
Tracking command:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\Tracker.exe ....
xxx.cpp
yyy.cpp
Done executing task "CL".
1>Done building target "ClCompile" in project "xxx.vcxproj".
so far, so good. Now the linker kicks in (well, it doesn't):
1>Target "Link" in file "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.targets"....
Using "Link" task from assembly "Microsoft.Build.CppTasks.Win32, Version=4.0.0.0...
Task "Link"
Using cached output dependency table built from:
link.write.1.tlog
Using cached input dependency table built from:
ink.read.1.tlog
Outputs for ....
MY.EXE
MY.PDB
All outputs are up-to-date.
Done executing task "Link".
Task "Message"
xxx.vcxproj -> my.exe
Done executing task "Message".
1>Done building target "Link" in project "xxx.vcxproj".
After checking all options we have in the property sheets one-by-one, it seems the sole source of this problem is that we have the intermediate directory set to a directory on another drive. We always do out of source builds in %TEMP%, and most of the time the projects reside on another drive.
Filed a bug report here including simple steps that reproduce the problem. Hopefully this gets fixed soon. Current soltuion is to set IntDir to a direcyory on the same drive as the project.
UPDATE
The bug report filed for this issue was closed as 'by design': it seems the Intermediate Directory should not be %TEMP% or %TMP% or any subdirectory of those. Disturbing, but at least I know what was wrong now.