How do I check or modify the #INC in Visual Studio? - visual-studio-2010

I was trying to build Chromium on Windows and met following error:
1>------ Build started: Project: webcore_bindings_sources, Configuration: Debug Win32 ------
1>Build started 9/6/2012 11:31:11 AM.
1>InitializeBuildStatus:
1> Touching "..\..\..\..\..\build\Debug\obj\webcore_bindings_sources\webcore_bindings_sources.unsuccessfulbuild".
1>CustomBuild:
1> ExceptionCodeDescription
1> Can't locate strict.pm in #INC (#INC contains: C:\chromium\src\third_party\WebKit\Source\WebCore\bindings\scripts /usr/lib/perl5/5.10/i686-cygwin /usr/lib/perl5/5.10 /usr/lib/perl5/site_perl/5.10/i686-cygwin /usr/lib/perl5/site_perl/5.10 /usr/lib/perl5/vendor_perl/5.10/i686-cygwin /usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at C:\chromium\src\third_party\WebKit\Source\WebCore\dom\make_dom_exceptions.pl line 33.
1> BEGIN failed--compilation aborted at C:\chromium\src\third_party\WebKit\Source\WebCore\dom\make_dom_exceptions.pl line 33.
It looks like my Perl path is not in the Visual Studio, so I'd like to add the path into this #INC, but not sure where to add it.

Try by setting the PERL5LIB environment variable.
There is this nice article which explains how to modify #INC on windows

Just found that this means cygwin is not mounted properly in Visual Studio.
The solution is:
In Solution Explorer go to the properties of the project
Go to Properties -> Build Events -> Pre-Build Event
On Command Line put:
$(SolutionDir)..\third_party\cygwin\setup_mount.bat
This thread has more details.

Related

VS Remote build - Visual studio resolves directory incorrectly

I had a functional remote build. Got a new Windows PC. Installed VS, set up same environment variables, pulled same source code from svn, pointed VS at the same remote machine using the same remote account.
Basic error is the windows (local) path is being concatenated to the linux (remote) one:
1>g++ : error : /home/tyler/vsBuildRoot/trunk/CoreTech/ThirdPartyTools/Encryption/Rijndael/Project/Linux/S/buildroot/CoreTech/ThirdPartyTools/Encryption/Rijndael/Project/Linux/../../Source/Rijndael.cpp: No such file or directory
Can anyone provide any hints as to how these inputs might result in the given outputs?
1>Target "ResolveRemoteDir" in file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Application Type\Linux\1.0\Linux.targets":
1> Using "ResolveRemoteDir" task from assembly "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Application Type\Linux\1.0\Microsoft.Build.Linux.Tasks.dll".
1> Task "ResolveRemoteDir"
1> Task Parameter:RemoteProjectDir=/home/tyler/vsBuildRoot/trunk/CoreTech/ThirdPartyTools/Encryption/Rijndael/Project/Linux/
1> Task Parameter:RemoteTarget=802522027;192.168.1.107 (username=, port=22, authentication=PrivateKey)
1> Task Parameter:ProjectDir=S:\buildroot\CoreTech\ThirdPartyTools\Encryption\Rijndael\Project\Linux\
1> Task Parameter:IntermediateDir=../../Build/Rijndael/Linux/LIB/Release/x64/
1> Task Parameter:RemoteProjectDirFile=../../Build/Rijndael/Linux/LIB/Release/x64/802522027.RemoteProjectDirFile.tlog
1> Task Parameter:RequireRemoteConnection=True
1> Output Property: _ResolvedRemoteProjectDir=/home/tyler/vsBuildRoot/trunk/CoreTech/ThirdPartyTools/Encryption/Rijndael/Project/Linux/S/buildroot/CoreTech/ThirdPartyTools/Encryption/Rijndael/Project/Linux
1> Done executing task "ResolveRemoteDir".
Some tasks correctly generate _ResolvedRemoteProjectDir, some do not. The key inputs always seem to be the same. I should note that this happens for multiple projects...which are clearly inheriting something different. I just can't figure out what.
I am very stumped.
Worth noting, that s: is a virtual drive that is sometimes referenced through various variables in our build. The physical drive never is. On this computer, that maps to c:\S_Drive. If I open the solution from there, the remote directory does change to c:\S_Drive

System.IO.IOException during the build process in VisualStudio 2017

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.

"The process cannot access the file 'Default.rd.xml' because it is being used by another process." on AppVeyor CI

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.

Windows Driver build - incorrect path passed to Inf2Cat.exe

I'm new to the subject of windows drivers. I'm trying to build one of the Windows-driver-samples in Visual Studio 2015. The compilation and linking steps pass without errors and then I get the following error:
TRACKER : error TRK0002: Failed to execute command:
""C:\Program Files (x86)\Windows Kits\10\bin\x86\inf2cat.exe"
/os:10_x64 /driver:x64\Debug\WFPSamplerCalloutDriver\".
The operation identifier is not valid.
(Note the relative path in /driver argument). If I call Inf2Cat manually from command prompt with full path to the driver, it passes without a hitch:
C:\Program Files (x86)\Windows Kits\10\bin\x86>Inf2Cat.exe /os:10_x64
/driver:C:\Users\****\Windows-driver-samples\network\trans\WFPSampler\sys\x64\Debug\W
FPSamplerCalloutDriver
...........................
Signability test complete.
Errors:
None
Warnings:
None
Catalog generation complete.
C:\Users\****\Windows-driver-samples\network\trans\WFPSampler\sys\x64\Debug
\WFPSamplerCalloutDriver\wfpsamplercalloutdriver.cat
So, it seems to me that VS somehow failed to provide the full path to the driver in the argument to Inf2Cat.
How can I fix this? Which configuration property of my project is incorrect?
Description
Seems Inf2Cat from SDK10 does not accept directory path format provided by VS Project Configurator. Works when: either output folder name has with no trailing "\" or folder name ends up with "\.".
Workaroud
Disable Inf2Cat under Project Preferences: Run Inf2Cat -> No
Configure build events under Build-Events->Post Build-Event: Command Line -> "$(WindowsSdkDir)bin\$(DDKPlatform)\inf2cat.exe" /os:10_$(DDKPlatform) /driver:"$(ProjectDir)$(IntDir)$(MSBuildProjectName)"

Vim errorformat for Visual Studio

I want to use Vim's quickfix features with the output from Visual Studio's devenv build process or msbuild.
I've created a batch file called build.bat which executes the devenv build like this:
devenv MySln.sln /Build Debug
In vim I've pointed the :make command to that batch file:
:set makeprg=build.bat
When I now run :make, the build executes successfully, however the errors don't get parsed out. So if I run :cl or :cn I just end up seeing all the output from devenv /Build. I should see only the errors.
I've tried a number of different errorformat settings that I've found on various sites around the net, but none of them have parsed out the errors correctly. Here's a few I've tried:
set errorformat=%*\\d>%f(%l)\ :\ %t%[A-z]%#\ %m
set errorformat=\ %#%f(%l)\ :\ %#%t%[A-z]%#\ %m
set errorformat=%f(%l,%c):\ error\ %n:\ %f
And of course I've tried Vim's default.
Here's some example output from the build.bat:
C:\TFS\KwB Projects\Thingy>devenv Thingy.sln /Build Debug
Microsoft (R) Visual Studio Version 9.0.30729.1.
Copyright (C) Microsoft Corp. All rights reserved.
------ Build started: Project: Thingy, Configuration: Debug Any CPU ------
c:\WINDOWS\Microsoft.NET\Framework\v3.5\Csc.exe /noconfig /nowarn:1701,1702 /errorreport:prompt /warn:4 /define:DEBUG;TRACE /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\PresentationCore.dll" /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\PresentationFramework.dll" /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.DataSetExtensions.dll" /reference:c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.Linq.dll" /reference:c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll" /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\UIAutomationProvider.dll" /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\WindowsBase.dll" /debug+ /debug:full /filealign:512 /optimize- /out:obj\Debug\Thingy.exe /resource:obj\Debug\Thingy.g.resources /resource:obj\Debug\Thingy.Properties.Resources.resources /target:winexe App.xaml.cs Controller\FieldFactory.cs Controller\UserInfo.cs Data\ThingGatewaySqlDirect.cs Data\ThingListFetcher.cs Data\UserListFetcher.cs Gui\FieldList.xaml.cs Interfaces\IList.cs Interfaces\IListFetcher.cs Model\ComboBoxField.cs Model\ListValue.cs Model\ThingType.cs Interfaces\IThingGateway.cs Model\Field.cs Model\TextBoxField.cs Model\Thing.cs Gui\MainWindow.xaml.cs Gui\ThingWindow.xaml.cs Interfaces\IField.cs Properties\AssemblyInfo.cs Properties\Resources.Designer.cs Properties\Settings.Designer.cs RequiredValidation.cs "C:\TFS\KwB Projects\Thingy\Thingy\obj\Debug\Gui\FieldList.g.cs" "C:\TFS\KwB Projects\Thingy\Thingy\obj\Debug\Gui\MainWindow.g.cs" "C:\TFS\KwB Projects\Thingy\Thingy\obj\Debug\Gui\ThingWindow.g.cs" "C:\TFS\KwB Projects\Thingy\Thingy\obj\Debug\App.g.cs" "C:\TFS\KwB Projects\Thingy\Thingy\obj\Debug\GeneratedInternalTypeHelper.g.cs"
C:\TFS\KwB Projects\Thingy\Thingy\Controller\FieldFactory.cs(14,19): error CS0246: The type or namespace name 'IFieldNothing' could not be found (are you missing a using directive or an assembly reference?)
Compile complete -- 1 errors, 0 warnings
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
UPDATE:
It looks like using msbuild instead of devenv is probably the right way to go (as per Jay's comment).
Using msbuild the makeprg would be:
:set makeprg=msbuild\ /nologo\ /v:q
Sample output whould be:
Controller\FieldFactory.cs(14,19): error CS0246: The type or namespace name 'IFieldNothing' could not be found (are you missing a using directive or an assembly reference?)
It looks like the tricky part here may lie in the fact that the path is relative to the .csproj file, not the .sln file which is the current directory in Vim and lies one directory above the .csproj file.
ANSWER:
I figured it out...
set errorformat=\ %#%f(%l\\\,%c):\ %m
This will capture the output for both devenv /Build and msbuild.
However, msbuild has one catch. By default, it's output doesn't include full paths. To fix this you have to add the following line to your csproj file's main PropertyGroup:
<GenerateFullPaths>True</GenerateFullPaths>
I have a blog post which walks through all the details of getting C# projects building in Vim, including the error format. You can find it here: http://kevin-berridge.blogspot.com/2008/09/vim-c-compiling.html
In short you need the following:
:set errorformat=\ %#%f(%l\\\,%c):\ %m
:set makeprg=msbuild\ /nologo\ /v:q\ /property:GenerateFullPaths=true
Copy from question to remove from 'unanswered' list
set errorformat=\ %#%f(%l\\\,%c):\ %m
This will capture the output for both devenv /Build and msbuild. However, msbuild has one catch. By default, it's output doesn't include full paths. To fix this you have to add the following line to your csproj file's main PropertyGroup:
<GenerateFullPaths>True</GenerateFullPaths>
I found an even better answer: use :compiler to use built-in efm settings.
" Microsoft C#
compiler cs
" Microsoft Visual C++
compiler msvc
" mono
compiler mcs
" gcc
compiler gcc
Note: It also sets the default makeprg. See $VIMRUNTIME/compiler/
Try running msbuild instead of devenv. This will open up a ton of power in how the build runs.
Open a Visual Studio Command Prompt to get your path set up. Then do msbuild MySln.sln /Configuration:Debug.
See msbuild /? for help.
I found this question when looking for errorformat for compiling c++ in Visual Studio. The above answers don't work for me (I'm not using MSBuild either).
I figured out this from this Vim Tip and :help errorformat:
" filename(line) : error|warning|fatal error C0000: message
set errorformat=\ %#%f(%l)\ :\ %#%t%[A-z]%#\ %[A-Z\ ]%#%n:\ %m
Which will give you a quickfix looking like this:
stats.cpp|604 error 2039| 'getMedian' : is not a member of 'Stats'
(with error highlighted) from
c:\p4\main\stats.cpp(604) : error C2039: 'getMedian' : is not a member of 'Stats'
As Simon Buchan mentioned you can use this in your project to generate the full paths in the output:
<GenerateFullPaths>True</GenerateFullPaths>
But you can make it more portable by adding /property:GenerateFullPaths=true to you makeprg instead of adding the above to your project files.
:set makeprg=msbuild\ /nologo\ /v:q\ /property:GenerateFullPaths=true\
None of these errorformats worked in Visual studio 2009 v9.0.21022.8 professional edition. Using cygwin, had to call devenv from bash which made setting makeprg a little tricky (screw batch files). Also had to tweak my errorformat when devenv splits into multiple processes and proceeds error message with "1>" or "2>" etc:
set autowrite
"2>c:\cygwin\home\user\proj/blah.cpp(1657) : error C2065: 'blah' : undeclared identifier
set errorformat=%.%#>\ %#%f(%l)\ :\ %#%t%[A-z]%#\ %[A-Z\ ]%#%n:\ %m
let prg="devenv"
let makepath=$MAKEPATH
let &makeprg='cmd /c "'.prg.' '.makepath.'"'
My .bashrc sets the MAKEPATH environment variable using cygpath to convert to a DOS compatible path:
export MAKEPATH="$(cygpath -d "proj/VC9/some.sln") /build \"Debug\""
If you have vim 6.x you can use :cw which is SO much better than clist (try searching for errors among hundreds of warnings and you know what I mean). Looking at vim tweaks makes me want to vomit but I'm in vim heaven!!! Good bye visual studio! Thanks for the base to tweak pydave +1.

Resources