For a while now I've been getting the following OUTPUT window when building a solution:
1>------ Build started: Project: Scheduler, Configuration: Debug Any CPU ------
1> Scheduler -> C:\Users\dubilm\source\repos\scheduler\Scheduler\bin\Scheduler.dll
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(4811,5): error MSB3541: Files has invalid value "<<<<<<< HEAD". Illegal characters in path.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I have tried Clean and Rebuild to no avail. The application works despite the reported error and updates have been deployed to production server with no issues. None of my other solutions/projects have any issues building.
The ERROR LIST window also lists the same error...
Severity = Error
Code =
Description = Files has invalid value "<<<<<<< HEAD". Illegal characters in path.
Project = Scheduler
Path =
File =
Project Rank = 1
Line =
Column =
Category =
Source = Build
Suppression State =
Tool
So no file indicated as the source of the error. The project is a web application .net vb MVC if this has any bearing.
Any suggestions of what else I can try to clear this error. Thanks
The <<<<<<< HEAD is what you get when trying to merge files, its used to indicate where the code starts (the old and the new one) sometimes when merging, some issues happen(ther could be a ton of diferent reasons) and you get stuck with that in the middle of your code, just use the search function (Ctrl + f) and search for <<<<<<< HEAD (make sure you had the search option in "search in this solution") you will see where it is, and if there is no duplicated code around, you can just erase it
I deleted the "bin" and "obj" folders and then cleaned the solution. It worked for me. Hope this will help.
Try unloading and reloading project. That worked for me.
Related
I'm working on a Hololens application using Unity 2018.2.20f1. I'm building the application for UWP from Unity without a problem. However, after opening up the generated solution in the VisualStudio 2017 (Community Edition) and trying to build it, the build process fails with the following errors:
Severity Code Description Project File Line Suppression State
Error MSB3073 The command ""D:\Projects\VSProjects\VirtualPrague\Il2CppOutputProject\\IL2CPP\build\il2cpp.exe" --libil2cpp-static --compile-cpp -architecture=x86 -configuration=Release -platform=winrt -outputpath="D:\Projects\VSProjects\VirtualPrague\\build\bin\Win32\Release\GameAssembly.dll" --data-folder="D:\Projects\VSProjects\VirtualPrague\\build\bin\Win32\Release\\" -cachedirectory="D:\Projects\VSProjects\VirtualPrague\\build\obj\il2cppOutputProject\Win32\Release\\" -generatedcppdir="D:\Projects\VSProjects\VirtualPrague\Il2CppOutputProject\\Source" --additional-defines=WINDOWS_UWP --additional-defines=UNITY_UWP --additional-defines=UNITY_WSA_10_0 --additional-defines=UNITY_WSA --additional-defines=UNITY_WINRT --additional-defines=PLATFORM_WINRT -dotnetprofile=unityjit -verbose --map-file-parser="D:\Projects\VSProjects\VirtualPrague\Il2CppOutputProject\\IL2CPP\MapFileParser\MapFileParser.exe"" exited with code -532462766. Il2CppOutputProject C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.MakeFile.Targets 44
and
Severity Code Description Project File Line Suppression State
Error LNK1181 cannot open input file 'D:\Projects\VSProjects\VirtualPrague\build\bin\Win32\Release\GameAssembly.lib' VirtualPrague D:\Projects\VSProjects\VirtualPrague\VirtualPrague\LINK 1
In the output there are multiple exceptions, similar to this one:
1>il2cpp.exe didn't catch exception: System.IO.IOException: The process cannot access the file 'C:\Users\dev\AppData\Local\Temp\tmpDE97.tmp' because it is being used by another process.
1> at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
1> at System.IO.File.InternalDelete(String path, Boolean checkHost)
1> at Unity.IL2CPP.Shell.Execute(ExecuteArgs executeArgs, IExecuteController controller)
1> at Unity.IL2CPP.Building.CppProgramBuilder.PostprocessObjectFiles(HashSet`1 objectFiles, CppToolChainContext toolChainContext)
1> at Unity.IL2CPP.Building.CppProgramBuilder.Build(IBuildStatistics& statistics)
1> at il2cpp.Program.DoRun(String[] args)
1> at il2cpp.Program.Run(String[] args)
1> at il2cpp.Program.Main(String[] args)
The exceptions are the same but were thrown for different files. I tried to reinstall the Visual Studio and managed to get a build. The next day I turned on the PC and this error was back. I stopped all of the VS instances and processed from the task manager, deleted all of the files from the Temp folder and managed to get a build a couple more times. Then this error came back.
From what I can tell, during the build process, Visual Studio creates some *.tmp files and for some reason thinks that another process is using it.
Any idea why this is happening and how can it be solved?
Thanks a lot!
Edit: So here is what I did so far (this is more of a work around rather then a solution)
Uninstall vs and unity
Clear the registry with ccleaner and Advanced Uninstaller Pro
Install vs and Unity
Every time I want to get a build I,
Close all of vs instances
Clear Temp folder (C:\Users\dev\AppData\Local\Temp)
Delete previous vs solution
Build from Unity
Run vs as Administrator
Build and deploy the solution from vs
And it works for the most the time. Also, changing the solution configuration (from debug to release and vice versa) helps sometimes.
I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.
I have a UWP app that compiles successfully if I have UseDotNetNativeToolchain off. But when I turn it on, it gives me the cryptic error:
Internal compiler error: Object reference not set to
an instance of an object. UWPApp C:\Program Files
(x86)\MSBuild\Microsoft.NetNative\x86\ilc\IlcInternals.targets 887 Build
This is all it gives me. What could be causing this? How can I drill down on this.
Using VS2015
Here is the full build output in case that helps:
https://gist.github.com/shannah/e24fe8456313fb9ad98577c9a812f357
The solution to this problem was to disable optimization in a few assemblies I was using in the Default.rd.xml file. E.g.
<Assembly Name="IKVM.OpenJDK.Core" Dynamic="All" DoNotInline="true" DoNotOptimize="true"/>
Can anyone help, the error I'm getting when I try to build a release? The error from the logs is as below:
Building .cab files...
ISEXP : error : -1501: Could not compress "F:\Nagarajan\Projects\Game\Game.opensdf" into "F:\Nagarajan\Projects\Game\Game Installer\Game Installer\Express\SingleImage\DiskImages\DISK1\Data1.cab"
Kindly help me. Thanks in advance
The .opensdf file is a temporary file, used by - and held open by - Visual Studio whiile you have your project open. It should not be part of your distribution, so you just need to remove it from the list of files packed by the installer.
I am trying to migrate one of projects earlier in VS2008 to VS2010. On building I get the following error
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(317,7): error MSB4094: "hdxBinding.idl;hdxBlinking.idl;HDXCommandObject.idl;hdxds.idl;HSCProcessStatus.idl;HSCSelectableWindow.idl" is an invalid value for the "Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem".
On clicking this error, it takes me to the line Source ="#(Midl)" inside C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets file
A Code Snippet in Microsoft.CppCommon.targets file:
<ItemGroup>
<Midl Condition="'#(Midl)' != ''">
<MinimalRebuildFromTracking Condition="'$(BuildType)' != 'Build' or '$(ForceRebuild)' == 'true'">false</MinimalRebuildFromTracking>
</Midl>
</ItemGroup>
<PropertyGroup>
<MidlToolArchitecture Condition="'$(MidlToolArchitecture)' == ''">$(DefaultToolArchitecture)</MidlToolArchitecture>
</PropertyGroup>
<MIDL
Condition ="'%(Midl.ExcludedFromBuild)'!='true'"
Source ="#(Midl)"
AdditionalIncludeDirectories ="%(Midl.AdditionalIncludeDirectories)"
AdditionalOptions ="%(Midl.AdditionalOptions)"
ApplicationConfigurationMode ="%(Midl.ApplicationConfigurationMode)"
ClientStubFile ="%(Midl.ClientStubFile)"
CPreprocessOptions ="%(Midl.CPreprocessOptions)"
DefaultCharType ="%(Midl.DefaultCharType)"
DllDataFileName ="%(Midl.DllDataFileName)"
EnableErrorChecks ="%(Midl.EnableErrorChecks)"
ErrorCheckAllocations ="%(Midl.ErrorCheckAllocations)"
ErrorCheckBounds ="%(Midl.ErrorCheckBounds)"
ErrorCheckEnumRange ="%(Midl.ErrorCheckEnumRange)"
ErrorCheckRefPointers ="%(Midl.ErrorCheckRefPointers)"
ErrorCheckStubData ="%(Midl.ErrorCheckStubData)"
ExcludedInputPaths ="$(ExcludePath)"
GenerateClientFiles ="%(Midl.GenerateClientFiles)"
GenerateServerFiles ="%(Midl.GenerateServerFiles)"
GenerateStublessProxies ="%(Midl.GenerateStublessProxies)"
GenerateTypeLibrary ="%(Midl.GenerateTypeLibrary)"
HeaderFileName ="%(Midl.HeaderFileName)"
IgnoreStandardIncludePath ="%(Midl.IgnoreStandardIncludePath)"
InterfaceIdentifierFileName ="%(Midl.InterfaceIdentifierFileName)"
LocaleID ="%(Midl.LocaleID)"
MkTypLibCompatible ="%(Midl.MkTypLibCompatible)"
OutputDirectory ="%(Midl.OutputDirectory)"
PreprocessorDefinitions ="%(Midl.PreprocessorDefinitions)"
ProxyFileName ="%(Midl.ProxyFileName)"
RedirectOutputAndErrors ="%(Midl.RedirectOutputAndErrors)"
ServerStubFile ="%(Midl.ServerStubFile)"
StructMemberAlignment ="%(Midl.StructMemberAlignment)"
SuppressCompilerWarnings ="%(Midl.SuppressCompilerWarnings)"
SuppressStartupBanner ="%(Midl.SuppressStartupBanner)"
TargetEnvironment ="%(Midl.TargetEnvironment)"
TypeLibFormat ="%(Midl.TypeLibFormat)"
TypeLibraryName ="%(Midl.TypeLibraryName)"
UndefinePreprocessorDefinitions ="%(Midl.UndefinePreprocessorDefinitions)"
ValidateAllParameters ="%(Midl.ValidateAllParameters)"
WarnAsError ="%(Midl.WarnAsError)"
WarningLevel ="%(Midl.WarningLevel)"
TrackerLogDirectory ="%(Midl.TrackerLogDirectory)"
MinimalRebuildFromTracking ="%(Midl.MinimalRebuildFromTracking)"
ToolArchitecture ="$(MidlToolArchitecture)"
TrackerFrameworkPath ="$(MidlTrackerFrameworkPath)"
TrackerSdkPath ="$(MidlTrackerSdkPath)"
TLogReadFiles ="#(MIDLTLogReadFiles)"
TLogWriteFiles ="#(MIDLTLogWriteFiles)"
ToolExe ="$(MIDLToolExe)"
ToolPath ="$(MIDLToolPath)"
TrackFileAccess ="$(TrackFileAccess)"
AcceptableNonZeroExitCodes ="%(Midl.AcceptableNonZeroExitCodes)"
YieldDuringToolExecution ="$(MidlYieldDuringToolExecution)"
>
</MIDL>
Can somebody please tell me whats going wrong here. This is driving me crazy!!!!!!
Got a similar error today on a project that I am converting to VS2010. I don't have a good solution to the problem yet, but I have a workaround. In my case, the project contained 2 idl files. Call them A.idl and B.idl. A.idl is the main idl for the project. It includes B.Idl. The error I received was:
error MSB4094: "A.idl;B.idl" is an invalid value for the "Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem".
It seems that the build system searched for all idl files in the project and made a single call to the MIDL compiler with all of them even though that was bound to fail. I don't know why VS2010 does that and earlier version didn't (or maybe earlier versions of MIDL could handle multiple inputs).
The workaround: grab the MIDL arguments off of MIDL Command Line page of the project's properties. Then run MIDL by hand in a VS2010 Command Prompt window using those args. In my case, since A.idl includes B.idl, I only needed to run one MIDL command:
MIDL options-copied-from-project-properties A.IDL
It looks like you have multiple idl files in your project (hdxBinding.idl, hdxBlinking.idl, etc.). So the same trick might work for you.
Good luck
I ran into this issue trying to build the DataMonitor example from the TMG SDK with Visual Studio 2010. The problem from what I can tell is the MIDL > Output settings in the project - the Header File, IID File, Proxy File, and Type Library were set to "DataMonitor...", which was forcing those settings to be applied to all included IDL files (and not just the project's generated one).
Changing those settings to use %(Filename) instead and the project built fine.
When there are multiple IDL files in the project I converted from VS 2008 to VS 2010, I got this error. Since one IDL I had was included in the other. I disabled building of the included IDL file and it resolved this error.
These errors prop up when migrating to VS2010 as the .idl file properties are not migrated by VS2010 migrator. I got a similar error and resolved this by manually adding these parameters from to VS2010. Once done you will be able to get rid of these build errors.
I run into the same problem as well. The fix was (very confusing) remove empty in the vcxproj file. I run out of time and have not got to the bottom of why it helps - defining not empty HeaderFileName fixes the problem as well, other empty elements do not cause this problem (e.g. DllDataFileName).
If you want to reproduce bug or process of my investigation just create hello world and add two idl files. It should work. However if you add ItemGroupDefinition with Midl.HeaderFileName it should start failing. One wild guess is that it has something to do with batching of tasks (working example calls MIDL task for each file separately).