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
Related
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)"
I want to user a Windows API called GetIscsiSessionList to get the information of session list.
I came across with a compile problem, VS2015 complains as follows:
VS complians of GetIscsiSessionList:
VS complians in header file Iscsidsc.h:
Iscsidsc.h is in C:\Program Files (x86)\Windows Kits\8.1\Include\um
. Since Iscsidsc.h is a Windows provided file, I don't understand why VS compiler will complain.
The order of include header files should be as follows:
iscsierr.h should be in front of iscsidsc.h
I am having a problem when trying to run a VS10 test suite through OpenCover, using mstest as my target application.
Running the tests directly with MsTest works with this command:
"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" /resultsfile:"<application_root_path>\UnitTestResults\MyProject.vsmdi.trx" /testmetadata:"MyProject.vsmdi" /testlist:"ServiceTests" /testlist:"DatabaseTests"
However, when trying to run the same command under OpenCover, like this:
OpenCover\Opencover.console.exe -register:user -target:"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" -targetargs:"/resultsfile:"<application_root_path>\UnitTestResults\MyProject.vsmdi.trx" /testmetadata:"MyProject.vsmdi" /testlist:"ServiceTests" /testlist:"DatabaseTests"" -output:<application_root_path>\UnitTestResults\Coverage
it fails, with the following error, regarding the .vsmdi.trx file (which I gather should be created by MsTest after the tests run):
Error occurred while loading document '<application_root_path>\UnitTestResults\MyProject.vsmdi.trx'.
Code: 0x800c0006
The system cannot locate the object specified.
So, basically, it complains that it cannot find the results file, before running the tests, but that file is supposed to be created at the end of the run.
Might this be an issue related to OpenCover, as the same params work when running directly with mstest?
I checked my paths and they all work out, even the one in the error is the path where the file should be generated by mstest.
Thanks.
It looks like you may need to escape your quotes when passing your data via targetargs
-targetargs:"/resultsfile:"<application...""
becomes
-targetargs:"/resultsfile:\"<application...\""
as detailed in the wiki on handling spaces.
Alternatively put your command to execute your tests in a cmd/bat file and then use opencover to execute that.
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).
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.