stevewillcock / grunt-msbuild Goto Github PK

Msbuild has moved its install location to program files.

http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx

There is no option to use that version currently.

We have a lot of diversity in configuration of build-machines and developer-machines. After installing VS2019, the previous version of grunt-msbuild started to fail due to #45

Making msbuildPath mandatory is blocking us from upgrading, since our 40-50 developers and 20+ teamcity/ azure devops build-machines does not have msbuild.exe at same location.

It must be frustrating to keep up with all the changes, but the complexity has to live somewhere...

It'd be cool if grunt-msbuild did a NuGet Package Restore before it invoked msbuild (just shell out to nuget restore)

I have a lot of duplication in the gruntfile because I didn't see way to set global options. Is this possible? If not, I'd like to request that feature.

msbuild myproject.proj /maxcpucount

It seems you need to use spawn instead of exec from child_process:

jakejs/jake#79
http://stackoverflow.com/questions/7725809/preserve-color-when-executing-child-process-spawn/8671997#8671997

unfortunately I'm not clued up enough with node to swap exec for spawn and send you a PR :(

I my environment I have Visual Studio Professional 2017 (15.9.28307.1321) and the Visual Studio Build Tools 2019 (16.8.30804.86) installed.
The configuration is as follow:

...
msbuild: {
			MyProject: {
				src: "src/MyProject.sln",
				options: {
					projectConfiguration: "Release",
					platform: "Win32",
					targets: ["Rebuild"],
					maxCpuCount: 2,
					verbosity: "quiet",
					inferMsbuildPath: true
				}
			}
		},
...

The problem is the automatic detection of the MSBuildPath via inferMsbuildPath does not work.
The used vswhere is called with the following parameters:

-latest -products * -requires Microsoft.Component.MSBuild -find MSBuild\\**\\MSBuild.exe`

the result is:

C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\amd64\MSBuild.exe
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\MSBuild.exe

When I remove the -latest I got all msbuild paths but the unneeded one are on top and the grunt_msbuild is taking always the first one:

C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\amd64\MSBuild.exe
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\MSBuild.exe
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\amd64\MSBuild.exe
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe

So I was thinking the adding of -version [15.0,16.0) should work and that is exactly the case.
Also just setting the -products option from * to
-products Microsoft.VisualStudio.Product.Professional
will lead to the correct result.

I think useful would be here to add one or two new options to be able to stear that misleading selection of the buildpath via vswhere.exe.
Maybe a new option like vswhereOptionVersion and vswhereOptionProduct could be added:

...
msbuild: {
			MyProject: {
				src: "src/MyProject.sln",
				options: {
					projectConfiguration: "Release",
					platform: "Win32",
					targets: ["Rebuild"],
					maxCpuCount: 2,
					verbosity: "quiet",
					inferMsbuildPath: true,
                                        vswhereOptionVersion: "[15.0,16.0)",
                                        vswhereOptionProduct: "Microsoft.VisualStudio.Product.Professional"
				}
			}
		},
...

What do you think, would you allow a pull request that allow the setting/overwriting of the two vswhere.exe options in the described way?

I'm getting:

Warning: stdout maxBuffer exceeded. Use --force to continue.
Aborted due to warnings.

I'm a bit of a grunt noob so apologies if this is not a grunt-msbuild specific issue.

I'm trying to pass false (default is true) for the BuildInParallel MSBuild param. Would this be passed in the buildParamaters object? It doesn't appear to be working correctly when doing it that way.

By default MsBuild hangs around in the background after a build keeping file handles open to dll's it has built or used as dependencies. This is causing failures on my build server due to file locks.

MsBuild can be told to shut down after a build by passing '/nodeReuse:false' which will fix the above issue.

Currently grunt-msbuild does not allow passing this flag through (or any other non grunt supported flags through).

I propose another config option called 'customArgs' is added which would allow passing these non standard flags through. E.g.

options:
....
customArgs:'/nr:false /xx:yy .....'

In line 157 when adding customArgs, only array indexes are being added...

for (var customArg in options.customArgs) {
  args.push(customArg);
}

I think it should be

for (var customArg in options.customArgs) {
  args.push(options.customArgs[customArg]);
}

Trying to use the version option to specify to compile on 4.5.2, but that value is not accepted as a valid number. What is the correct way to compile using 4.5.2

Would be really good to have an ability to specify a custom fallback version. There is a common scenario when different people in team use different tools (e.g. different versions of VS).

If the projectPath has spaces it will fail

var projectPath = path.normalize(path.resolve() + '/' + src);

should be replaced for

var projectPath = '"' + path.normalize(path.resolve() + '/' + src) + '"';

When you install the current RC for VS2017, grunt-msbuild fails to find the msbuild executable with message:

Fatal error: Unrecognised MSBuild version "15"

This does not depend on any changes to the project files, just on the new VS being installed on the machine.

The actual path depends on the version of VS2017 installed:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin

When building, this results in error:
The system cannot find the path specified.
Warning: Command failed: "C:\git\ncore\node_modules\grunt-msbuild\bin\vswhere.exe" -latest -products * -requires Microsoft.Component.MSBuild

We use VS 2017

I'm updating a UWP app from VS 2015 to 2017, and in the process I started getting the same build errors mentioned in this thread when building on a Jenkins server and using grunt.

https://social.msdn.microsoft.com/Forums/vstudio/en-US/23c8df57-9c50-476c-9f56-1fe058e75a9d/uwp-app-builds-on-local-machine-fails-on-build-agent-systemprivatecorelib-not-found

First of many compile errors:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(1251,5): error MSB3816: Loading assembly "f:\j\workspace\MyApp\buildfolder\packages\Microsoft.NETCore.Portable.Compatibility\1.0.2\runtimes\aot\lib\netcore50\mscorlib.dll" failed. System.IO.FileNotFoundException: Could not load file or assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. [f:\j\workspace\MyApp\buildfolder\MyProject\MyProject.csproj]

And as it says in the answer to that forum thread, the solution is to use the 32-bit version of MSBuild and not the 64-bit. I've verified that the build completes successfully if I change this. That's also recommended at the end of this page.

https://msdn.microsoft.com/en-us/library/dn600634(v=vs.110).aspx

Unfortunately grunt-msbuild is currently hardcoded to use the amd64 version in inferMSBuildPathViaVSWhere when building with VS 2017. It would be great if you could make this configurable, using options.processor that is used elsewhere.

The path for the VS13 version of MSBuild is hardcoded to

"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe"

...but it's also possible for MSBuild to be installed in

"C:\Program Files\MSBuild\12.0\Bin\MSBuild.exe"

I'm guessing we'll need to check both locations and use the first one we can find.

Is there any way of specifying to options, and choose which to build by input params? I want to be able to choose wether to create a debug or release build. This setup builds both debug and release builds it seems. I would like to call grunt --debug or grunt --release. Is that possible?

    msbuild: {
        debug: {
            src: ['my.web.csproj'],
            options: {
                projectConfiguration: 'Debug'                    
            }
        },  
        release: {
            src: ['my.web.csproj'],
            options: {
                projectConfiguration: 'Release'                    
            }
        },
    },

Is there a way to publish a MVC.Net profile with your plugin?

See:
http://stackoverflow.com/a/3098613/131157
http://stackoverflow.com/a/16246739/131157

For build servers, and to generally enhance flexibility

The new folder is this:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64\MSBuild.exe

Your string building uses a version number when constructing the path. I did try to modify it myself however, I think the logic needs to be significantly changed due to a combination of vswhere.exe output, and the quirky version folders in general.

Would you accept a pull request which just allows the dev to pass the full msbuild path?

msbuild: { dev: { src: [projectDir + pkg.name + '.csproj'], options: { msbuildPath: 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\MSBuild\\Current\\Bin\\amd64\\MSBuild.exe', projectConfiguration: 'Release', targets: ['Clean', 'Rebuild'], buildParameters: { PostBuildEvent: '' } } } },

Then createCommand becomes :

` function createCommand(options) {
if (options.msbuildPath != undefined){
return options.msbuildPath;
}
...

`

Updating from 0.1.x to latest (0.3.4) yields the following error upon build:

Building Migrate.msbuild
Using MSBuild at:C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
Using maxcpucount: 4
Using cmd: C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
Using args: [ 'Migrate.msbuild',
  '/target:Migrate',
  '/verbosity:minimal',
  '/nologo',
  '/maxcpucount:4',
  '/property:Configuration=local',
  '/property:DryRun=False',
  '/property:Verbose=False',
  '/property:RollbackSteps=1',
  '/property:ConnectionString=Data Source=COMPUTERNAME;Initial Catalog=MYDATABASE;Integrated Security=True;' ]
MSBUILD : error MSB1005: Specify a property and its value.
Switch: /property:ConnectionString=Data Source=COMPUTERNAME;Initial Catalog=MYDATABASE;Integrated Security=True;

For switch syntax, type "MSBuild /help"
close received - code:  false
MSBuild failed with code: 1Migrate.msbuild
Warning: MSBuild exited with a failure code: 1 Use --force to continue.

My grunt config is using the following:

msbuild: {
  options: {
    projectConfiguration: 'Dev',
    targets: ['Clean', 'Rebuild'],
    maxCpuCount: 4,
    verbosity: 'minimal',
    stdout: true,
    buildParameters: {
      WarningLevel: 2,
      DeployOnBuild: false
    },
  },  
  migrate: {
    src: ['Migrate.msbuild'],
    options: {
        targets: ['Migrate'],
        buildParameters: {
          DryRun: 'False',
          Verbose: 'False',
          RollbackSteps: '1',
          ConnectionString: 'Data Source=COMPUTERNAME;Initial Catalog=MYDATABASE;Integrated Security=True;'
        },
        verbosity: 'minimal',
    }   
  }
}

It seems that the ConnectionString property is the culprit - if removed the build works. Searching the internet seems to indicate the need to escape or quote property values with a semicolon properly. I've tried a number of permutations of quotes to no avail. Any thoughts?

Hi

The task doesn't continue to the next task, when completed

Example:
grunt.registerTask('test', ['clean', 'msbuild', 'copy', 'zip']);

The 'copy' and 'zip' are not executed. I fixed it by added to msbuild.js line 44

Original:
async.series(projectFunctions);
New:
async.series(projectFunctions, function() { cb(); });

Cheers

Ken

It seems that it's not possible to set the version as 4.5 or 4.5.1.
Here I can see that the version array is set only up to 4.0.

The current usage of vswhere for finding MSBuild >= 15.0 doesn't work doesn't seem to work with standalone installations of VS2017 Build Tools. This can be fixed by adding the argument "-products *" to the execution. Here are a couple of screenshots demonstrating the usage in an environment with build tools installed vs. and environment with VS2017 Professional installed:

Build Tools

VS 2017 Professional

We've got some developers using VS12 and some VS13. This seems to cause some issues as grunt-msbuild only handles one MSBuild path.

I'm unsure what the proper solution is, but I took a stab at a possible fix here: #13

Could you make this grunt task support absolute path for .csproj file?
Currently, It seems that only relative path is allowed.

Here's my config, I keep getting the error:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(132,5): error MSB4
184: The expression "[System.IO.Path]::GetExtension(C:UsermheroldSiteluetreenetwork.comWeb PlatformPropertiesPublis
hProfiles est.bluetreenetwork.com.pubxml)" cannot be evaluated. Illegal characters in path. [C:\Users\bmherol
d\Sites\bluetreenetwork.com\Web Platform\Web Platform.csproj]
Build failed BlueTree Network.sln

msbuild: {
    test: {
        src: ['BlueTree Network.sln'],
        options: {
            projectConfiguration: 'Test',
            targets: ['Clean', 'Rebuild'],
            stdout: true,
            maxCpuCount: 4,
            buildParameters: {
                WarningLevel: 2,
                DeployOnBuild: true,
                PublishProfile: "C:\Users\bmherold\Sites\bluetreenetwork.com\Web Platform\Properties\PublishProfiles\test.bluetreenetwork.com.pubxml",
                AllowUntrustedCertificate: true,
                Password: "PASSWORD HERE",
                Configuration: 'Test'
            },
            verbosity: 'quiet'
        }
    }
}

Any thoughts?