Vim errorformat for Visual Studio - 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.

Related

Visual studio doesn't let compile "Sgen could not be run"

Getting the error:
"The specified task executable "sgen.exe" could not be run. The filename or extension is too long F:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 3408"
And Warning:
"The command-line for the "SGen" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "SGen" into multiple calls with fewer parameters per call. DAYAnalytics F:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 3408"
At this part of Microsoft.Common.CurrentVersion.targets :
<SGen
BuildAssemblyName="$(TargetFileName)"
BuildAssemblyPath="$(IntermediateOutputPath)"
References="#(ReferencePath)"
ShouldGenerateSerializer="$(SGenShouldGenerateSerializer)"
UseProxyTypes="$(SGenUseProxyTypes)"
UseKeep="$(SGenUseKeep)"
KeyContainer="$(KeyContainerName)"
KeyFile="$(KeyOriginatorFile)"
DelaySign="$(DelaySign)"
ToolPath="$(SGenToolPath)"
SdkToolsPath="$(TargetFrameworkSDKToolsDirectory)"
EnvironmentVariables="$(SGenEnvironment)"
MSBuildArchitecture="$(SGenMSBuildArchitecture)"
SerializationAssembly="$(IntermediateOutputPath)$(_SGenDllName)"
Platform="$(SGenPlatformTarget)"
Types="$(SGenSerializationTypes)">
The explanation is pretty straightforward, But I don't understand how to fix it.
How do I reduce the command line length?
Set the "Generate serialization assembly" option in the Build options to "Auto" or "Off", unless you need them (that is, you make extensive use of the XmlSerializer), in which case you'll find more info here: Generating an Xml Serialization assembly as part of my build

visual studio 2015 c++ sddl.h does not appear as external dependency

I am trying to use the function ConvertSidToStringSid() in a Visual Studio 2015 Community, console project.
According to the msdn page
https://msdn.microsoft.com/en-us/library/windows/desktop/aa376399(v=vs.85).aspx
the requirements are:
Minimum supported client: Windows XP [desktop apps only]
Minimum supported server: Windows Server 2003 [desktop apps only]
Header: sddl.h
Library: Advapi32.lib
DLL: Advapi32.dll
I am using a Windows 10 Home, 64-bit computer. I have the *.lib and *.dll files respectively in :
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\um\x64\AdvAPI32.Lib
C:\Windows\System32\advapi32.dll
When i fill in the "#inclucde " in stdafx.h, I get no error from Intellisense. In contrast, "#include <blah.h>" gives a red wiggling underline under the 'include', and a mouse-over says 'Error: Cannot open source file "blah.h"'.
In my .cpp source file, which includes "stdafx.h", I add the code
BOOL OK ... ;
PSID owner;
char *sOwner;
OK = ConvertSidToStringSidW(owner, sOwner);
but then I get the red wiggle under ConvertSidToStringSidW.
In the solution explorer, under the project, under External dependencies there are files SCardErr.h and sdkddkver.h, but nothing, no sddl.h, between these two. (And, by the way, sddkver.h defines _WIN32_WINNT_THRESHOLD 0x0A00. Testing with IntelliSense in the editor, _WIN32_WINNT is also 0x0A00.)
When compiling, I first got an error message that the file sddl.h could not be found. I have multiple copies on the computer, and added to the "Additional include directories" for all configurations, the directory
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\shared
Compiling still fails with "identifier xxx is undefined" and 'xxx': Identifier not found, from IntelliSense and Build respectively.
The header sddl.h is still not in the external dependencies. Right-clicking on the sdksddkver.h I get its full path: The newly added additional include directory. I don't know what it was before I added this include directory.
Right clicking on the include directive in stdafx.h, I can open sddl.h. The editor shows parts of the contents in a light grey color, when the contents is guarded by an #if/#ifdef directive whose argument is false. However, the function I want to use, ConvertSidToStringSid, is shown in full color.
Unsure if its a clue that the error messages say "defined" rather than "declared". In the project properties, linker, input, additional dependencies, the file advapi32.lib is listed.
What am I doing wrong?
I found the solution myself. The problem was that I had two projects in the same "solution", each with its own stdafx.h file. I had the wrong stdafx.h file open in the editor, and placed the #include directive in the wrong file.
-Thanks

How do I check or modify the #INC in Visual Studio?

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.

Where is TextTransform.exe Located on Hard drive?

Where is TextTransform.exe located?
I'm trying to implement the solution in this post:
Get Visual Studio to run a T4 Template on every build
However I'm getting an error
"'TextTransform.exe' is not recognized as an internal or external command,
operable program or batch file."
I have been looking through the program files, however not sure where TextTransform.exe is located.
It should be below
\Program Files\Common Files\Microsoft Shared\TextTemplating\
see: http://msdn.microsoft.com/en-us/library/bb126245.aspx
Anyone coming to this question that's using VS 2017 or later should be using vswhere to locate this file. #codingdave's comment is the closest but that still won't work on many computers.
I've added an example to the Microsoft Docs article feedback that shows how to do this with Powershell.
#the path to VSWhere.exe is always in programfiles(x86)
$progFilesx86Path = [System.Environment]::ExpandEnvironmentVariables("%programfiles(x86)%")
$vsWherePath = Join-Path $progFilesx86Path "\Microsoft Visual Studio\Installer\vswhere.exe"
# this tells vswhere to use paths of the latest version of visual studio installed
# to locate this exe anywhere in those paths, and return a single textual
# value (not a json object or xml payload)
$ttExe = & $vsWherePath -latest -find **\TextTransform.exe -format value
if (-Not(Test-Path $ttExe)){
throw "Could not locate TextTransform.exe"
}
#then to invoke a transformation
& "$ttExe" c:\Source\YourTransform.tt
From #codingdave's comment
For VS2017, VS2019 location of TextTransform.exe will be
C:\Program Files (x86)\Microsoft Visual Studio\<<Version>>\<<Edition>>\Common7\IDE
Version -> (2017/2019)
Edition -> (Community/Professional/Enterprise)
And in pre build event we can use macro like
"$(DevEnvDir)\TextTransform.exe" "$(ProjectDir)AssemblyInfo.tt"
I would recommend trying this over that solution: http://www.olegsych.com/2010/04/understanding-t4-msbuild-integration
If you don't have VS 2010, though, I suppose you're stuck doing it the hard way.

Build FAILED for Notepad++ with message PostBuildEvent: The system cannot find the file specified

I get a build failure due to a post build event failure when building Notepad++ in VS 2010.
Here's the message from Output window:
PostBuildEvent:
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "copy ..\src\config.xml ..\bin\config.xml
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: copy ..\src\langs.xml ..\bin\langs.xml
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: copy ..\src\stylers.xml ..\bin\stylers.xml
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073:
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 1.
Please help
Posting the answer for others who might run into this issue
After a little research on this subject,
I learned that the XML file names that are specified in the projects Post-Build Event have changed, so you have to update that to use the new file-names
You can fix this by modifying the project file like this:
In Visual Studio,
Select the Project (Notepad++) and choose Project > Properties from VS Menu (or hit ALT + F7)
In the Property Pages window,
expand the Configuration Properties node
then, expand the Build Events node
Select Post-Build Event to view its properties
Modify the Command Line Property to look like this:
copy ..\src\config.model.xml ..\bin\config.model.xml
copy ..\src\langs.model.xml ..\bin\langs.model.xml
copy ..\src\stylers.model.xml ..\bin\stylers.model.xml
Click OK and Build away...
Also, be careful of spaces in the path. I just wasted a half hour convincing myself that the paths in a Pre-Build copy step were indeed correct (they were).
Got bitten by spaces in the path. Instead of copy d:\a path\*.dll d:\b path\ you want to quote it, like this:
copy "d:\a path\\*.dll" "d:\b path\"
Not specific to Notepad++ but I had a similar problem with a recent post-build step. When you see...
PostBuildEvent: The system cannot find the file specified.
..your source path is wrong. In my case I was using the wrong relative source path. And this fixed it:
copy /Y $(TargetName).* $(ProjectDir)..\Latest

Resources