Since our Windows compilation environment always requires vcvarsall.bat, and since our experience with Jenkins slaves as a service has been very bad, we configure a batch file that starts the Jenkins slave agent. Before starting the Jenkins slave agent, the batch file sets environment variables for various needs. Things like:

CALL "c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"

SET JAVA_HOME=C:\Program Files\Java\jdk1.7.0_21
SET ANT_HOME=C:\apache-ant-1.9.0

SET PATH=tools;C:\Program Files (x86)\Git\bin;%ANT_HOME%\bin;%JAVA_HOME%\bin;%PATH%

javaws javaws http://172.16.16.254:8080/computer/%COMPUTERNAME%/slave-agent.jnlp

I would like to see something similar, but I am not sure 'configure jenkins' (the global config) is the right spot to place TOOLSET configurations when they are node specific.... (can be installed anywhere on the node)

Mark - how do you call the vars when jenkins is running as a windows service.

We don't run Jenkins as a Windows service. Running Jenkins slaves as a Windows service creates several problems which are showstoppers in our environment.

Some of our tests need to run on the Windows desktop (Selenium, exe playback tests, etc.).

Other of our tests need access to the desktop environment, even if they don't display on the desktop (using the desktop to pass messages between apps, etc.).

It has been much simpler for us to configure "auto-login" on our slave agents and add a batch file to startup to launch the Jenkins slave agent rather than attempt to configure a service which can interact with the desktop and behave as though it were a desktop.

It also seems more "natural" to me that I should not alter a Windows service to have desktop access. I think that Windows services are generally not intended to access the desktop, and tests which need to run as a service should not have desktop access.

Rather than using the MSBuild launcher, you could run use a batch file within the job, and call vcvarsall.bat from that batch file, then call msbuild from within the batch file.

I have struggled with this issue this week. It seems to me that, for users who run Jenkins as a service on Windows, the MSBuild plugin needs to support vcvarsall.bat. Meanwhile, I am just running MSBuild from a Windows Batch Step, which defeats the point of having the plugin.

A contribution on the mailing list suggested putting the contents of vcvarsall.bat into a properties file and applying it using the Environment Injector Plugin for use by the MSBuild plugin. I haven't tried that.

May I suggest that, at least, some guidance is given on the MSBuild plugin wiki page about this issue?

This is now possible with the help of a plugin I have created: https://wiki.jenkins-ci.org/display/JENKINS/vcvarsall+Plugin

Thanks very much, Nathan! I don't see the plugin in the update center on my local Jenkins, even when I refresh. I also don't see it on https://updates.jenkins-ci.org/download/plugins/ .

Have you requested hosting of the vcvarsall plugin?

Is there a location where I can find the source code so that I can compile it myself before it is available from the update center?

nathan_osman any further progress on publishing this plugin to the Jenkins update center? Alternately, if you're willing to share it as open source, I'm willing to build it myself.

markewaite sorry for the delay - somehow I didn't see the notification.

I thought that the plugin would automatically appear in the update center once it was moved to the Jenkins GitHub organization but apparently this is not the case. I tried reaching out to the team via IRC but haven't heard back from them yet. The wiki page I created doesn't seem to be working either.

In the meantime, you can find the source code here: https://github.com/jenkinsci/vcvarsall-plugin.

nathan_osman thanks for your work on the plugin. I compiled the tip of the master branch and used it in my Visual Studio 2017 Community Edition environment. Three Windows machines are agents of a docker master hosted on a Linux machine.

When I clicked through the user interface to assign Visual Studio 2017 x64 on each of those machines, the web page that configures the agent hung as soon as a I clicked the apply or save button. I saw in your commit messages that Visual Studio 2017 support is a recent addition. Are you still working on Visual Studio 2017 support?