Is there a way to make sure that all of the environment variables from MSBuild are propagated to the batch scripts that I am calling from my custom build steps? It would be really nice to use variables like %CONFIGURATION% and %TARGETPATH% in the batch files...
Not OOTB - you'll see lots of cases where chaining of build steps selectively whitelists batches of e.g. 50 parameters.
The problem is that 'properties' ion MSBuild includes variables, input environment variables and much more, which would quickly overflow the OS limits (and sensible maximums) on environment size.
You could whack a pile of SETs together with a WriteLinesToFile and/or invoke a batch file tha has such SET statements.
Another approach, if you're using 4.0 is to use the PowerShell task to create a cusotm script inline and execute it.
Related
I have a solution where I am running various load test scenarios via the command line for Visual Studio 2017. I know I can use MSTest to do this, and am using /testcontainer arg for picking which .loadtest file, and the Set Test.UseRunSetting= WhateverRunSetting arg to pick which run setting I want (controller duration, context parameters, etc).
I can't seem to find a way to change the Step Load Pattern from command line, however. This would allow me to, from the command line, set things like ramp up time, max users, initial users, and other flags. The other way I can think to do this is if I can say which scenario to run (instead of all scenarios in the .loadtest file) based on a command line arg.
Well, the route I used was to write a Powershell script that accepts the parameters I want, such as initial users, step duration/ramp time, context parameters, max users, etc. Then takes those and edits my .loadtest file (since it's an XML file) and saves the .loadtest with the edits, including setting it as the active run-setting.
Then using MSTest as noted above, I can make sure that run setting and .loadtest is used and kick off my test(s).
Another way to do this is use of plug-ins. You can create a plug-in in your load test. The plug-in will read the external excel or xml file to control the user load. You can modify the excel or xml through automation.
I have same thought as yours for modifying load test files externally. Never thried though.
With Makefiles I'm used to being able to write things like:
includedir=$(shell pg_config --includedir)/server
to run an external program, pg_config, with argument(s) --includedir, and include the result in a variable or as part of a variable. So if pg_config --includedir output /usr/include to stdout, the value of includedir would become:
includedir=/usr/include/server
Is there any way to do the equivalent with a Visual Studio project? Run a command, get the result, and substitute it into a property?
I find myself having to edit properties pages all over the place - changing the include directories and library directories for both the x86 and x64 configurations of a project whenever I want to build an extension against a different PostgreSQL version. It is intensely frustrating.
I want to be able to put something like this into Configuration Properties -> C/C++ -> General -> Additional Include Directories:
%(shell pg_config --includedir)
or even better:
%(shell %(PG_CONFIG) --includedir)
where %(PG_CONFIG)'s location is defined in a single place for each platform in the project.
So I'm looking for at least user-defined macros, and preferably the ability to invoke a command line tool and replace the macro with the resulting standard output.
(Preferably in a way that doesn't involve delving into semi-documented UI elements that move and get renamed in every VS version, and that appear and disappear from the various Express editions).
This has been possible in Makefiles for 20 years, there must be a way to do it in VS, right? Or do "Real Windows Developers" generate their VS projects with scripts and build them using MSBuild?
I've looked at some similar questions without finding much of use, e.g.:
Visual Studio - Where to define custom path macros?
In particular, I'm aware of property sheets (View -> Other Windows -> Property Manager), but they don't seem to provide a way to set a value in just one place, they're still per-configuration and per-architecture, so if you have four configurations and two architectures it gets awkward. Unlike with the normal project property editor you can't even apply a change across a group of architectures/configurations, either.
I could use a VS extension, but they require installation into the user's VS, can be version-specific, and seem like a very big hammer for a small problem.
I find myself having to edit properties pages all over the place
That bugged me to no end as well. Property sheets to the rescue! When setting up a major solution in VS10, for example, I had every project pull in a settings.props that contained the common settings, made in only one place. Then go through all the generated or imported projects and kill any explicit value (even if blank) for everything possible. That way things will inherit from property sheets. Select "all configurations" and on each properly use the drop-down to "inherit from...".
I have property sheets for each special library too, just defining the proper #define, include paths, lib paths, etc. Projects that use that particular external lib simply use that property sheet. Users are told, in the worst case, to “edit the XML to change the path to where you have Boost”.
As for setting such a properly to a dynamic determined value, you can do that too. There are property functions you can use.
It sounds like you're going down the same path as I did.
More notes: “prop sheets are per configuration/platform”: If you include a prop sheet at the top-level node for the project itself (not the Debug|Win32, etc. child nodes) it will include it into all current configurations at once. If you edit the properly page, you can choose Multiple or All configurations on the Property dialog box, just as with the usual project use of the Property dialog.
“Custom user macros are well hidden” A property page shows up for that when in a property sheet you created, but not when opening property dialog on a proj file as in the normal File View. The macro will be set in one place (the prop page) and usable as a $(name) in all projects that include it, and even in other property pages that come later in the evaluation sequence.
Let me know how it goes. You should be able to do everything you asked.
—John
In addition to #jdlugosz's answer:
It looks like the traditional way to do this with Visual Studio, before the advent of property functions, was to write a new MSBuild Task. The task can potentially do things like modify a property sheet.
MSBuild supports "inline tasks" where the task code is in the MSBuild project file, rather than a separate assembly, so it might not be neccessary to create a new subproject just for the task.
There are a bunch of built-in tasks, like Exec and CreateProperty that may be useful.
The docs say that:
[The Exec task] is useful when a specific MSBuild task for the job that you want to perform is not available. However, the Exec task, unlike a more specific task, cannot gather output from the tool or command that it runs.
... but that seems to be outdated/wrong so you don't need horrible workarounds.
So, prior to .NET 4.5 I'd probably have to write a custom task for this simple job, because there's no way to feed the command stdout/stderr into the CreateProperty task or have Exec create a property directly. But in 4.5 it looks like I can do it directly. At least in VS Express support for tasks etc is very limited so you'll probably land up editing the XML.
I work on software that requires access to DLLs, usually wants environment variables set a certain way, and can take command line parameters. I'm generally opposed to setting/modifying system-wide environment variables for the purpose of launching these apps, since I might want to use different dependencies (different dlls), etc. and I don't want to accidentally get the wrong DLL loaded.
Up until now, I've been generating the visual studio .vcproj.user files and matching batch files from cmake ( see here for my script ) that extends the path to include the path to my dlls, sets any other environment variables as needed, and launches the application, forwarding all the command line arguments. (I do the same on Linux, but it's simpler because of RPATH). When we want to launch with a command line argument that wasn't just a file we could drop on the batch file, what we did is copy the batch file and edit the command to add our argument. (It's all GUI applications, but config files/flags can be passed on the command line)
This has become quite a hassle for me and my colleagues, and we end up with a ton of batch files, named similarly and difficult to maintain. It's not really a great interface for starting but there's a lot of apps we either use or develop that are like this, so it's a common task.
My question is this: I'd like a nicer way to configure dynamic library search paths, process-local environment variables, working directory, executable, and arguments for starting a program than hand-editing a batch file every time. I've done some digging to try to find one, but haven't been successful - "launcher" tends to bring me to "search-as-you-type" tools for frequently-used apps, and "command line argument" tends to find recommendations to use batch files. (It's not a windows-specific issue, either, but the dynamic library path stuff is less problematic during the code/compile/run cycle)
I've made a quick mockup of what I'm envisioning: it seems like the kind of thing that has to exist somewhere. Do you know of a tool similar to this (preferably cross-platform, and open source is even better)? It doesn't need all bells and whistles I put in the mockup, but that's what I'd build if I had time to build it myself. Thanks!
I am running the datasvcutil.exe command in a prebuild event.
datasvcutil.exe is located in "C:\Windows\Microsoft.NET\Framework64\v4.0.30319" (on 64 bit machines.)
I can just hard code this as C:\Windows\Microsoft.NET\Framework64\v4.0.30319\datasvcutil.exe, but that seems rather brittle. When a hypothetical .net v4.0.30320 comes out my prebuild event will not work anymore.
With the Visual Studio Command prompt, I can call datasvcutil.exe with out the path. I am wondering if there is a similar indirect way to call this from my pre-build event command line.
Since the tool you need is in the same path as MSBuild.exe you could simply reference it with $(MSBuildBinPath)\DataSvcUtil.exe which would make it also independent of Framework / Framework64
I like Filburts answer above. But if you really want to be courageous, you can invoke:
%VS100COMNTOOLS%\VCVarsQueryRegistry.bat
rem and query one of the %FrameworkDIR32% or %FrameworkDIR64% environment variables, depending on your choice
If you are even more courageous, MSBuild is capable of reading registry by itself - the following link may help: http://msdn.microsoft.com/en-us/library/ms171458.aspx (check the "Registry Properties" section)
What we are looking for is: while compiling the same configuration, say Release|Win32, is there a way to only do the postbuild steps sometimes. Like, if I am on a dev machine do all the post-build steps or if I am on a build server then don't do them. Or is the only way to accomplish this is by implementing a new configuration?
Commenters: Thanks for the ideas, we do not want to use scripts as they would be one more thing to maintain, and going to MSBuild proj files would be a lot of headache at this point as well. Thanks for trying though.
You could use environment variables in the post build script. Something like this:
if NOT %ComputerName% == DEVMACHINENAME GOTO end
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen "$(TargetPath)"
:end
If you want to crack into MSBuild itself (.*proj files are essentially just MSBuild scripts), you can run machine-specific steps post-build: http://flimflan.com/blog/MachineSpecificTasksWithMSBuild.aspx
"This takes advantage of the fact that all environment variables are immediately available as properties in an MSBuild script; and that all Windows machines (that I've worked on recently) have the COMPUTERNAME environment variable set."
Would it be possible to implement your post build steps as an external script which is always executed, but has logic to conditionally perform the steps you require?
If you don't like to have a separate build configuration (which I think would make most sense) you could e.g. define an environment variable on your build server which you then can test for in you post-build script.