VS 2019: Create an environment variable to use in test projects - testing

Is there an option to set, in Visual Studio 2019, environment variables that can be read by test code, when running using the built-in test explorer?
In my test project's properties, I've tried defining the env variable under the 'debug' tab, but I wasn't able to read it in my test code.

Related

CMake set different Debug and Release working directories in Visual Studio

Is there a possibility to set different working directories (VS_DEBUGGER_WORKING_DIRECTORY) for Debug and Release builds in a CMake generated Visual Studio project?
If I write
set_target_properties(${PROJECT_BIN} PROPERTIES
VS_DEBUGGER_WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/Debug")
Selecting Project Properties > Debugging > Working Directory will display
C:/Users/Alexandru/Documents/MyProject/Build/Debug
for both Debug and Release configurations, but I want
C:/Users/Alexandru/Documents/MyProject/Build/Release
for the Release configuration.
I also tried setting VS_DEBUGGER_WORKING_DIRECTORY_DEBUG and VS_DEBUGGER_WORKING_DIRECTORY_RELEASE but it seems these properties don't exist.
If there are no configuration specific properties and generator expressions like $<CONFIG> don't work (tested it with VS_DEBUGGER_WORKING_DIRECTORYto no avail), you can still use VS variables:
set_target_properties(${PROJECT_BIN} PROPERTIES
VS_DEBUGGER_WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/$(Configuration)")

Modify website MSBuild options to include configuration in path

I'm in the process of updating an old solution from Visual Studio 2005 to Visual Studio 2015, and I'm trying to reproduce as much of our old kludgy behavior as we safely can to minimize the downstream effects. I'm currently running into an issue with the Website Property Pages and MSBuild.
The path here is mostly correct, except that we want the configuration used to be in the path as well. So a Debug build will go into E:\Projects\...\PrecompiledWeb\Debug\MyService and a Release build will go into E:\Projects\...\PrecompiledWeb\Release\MyService. Is this doable? Is there a variable I can insert to make that determination when building?
We're using msbuild against the containing solution file (via TeamCity if it matters, but I can replicate it without it).
Edit: I've found the Debug.AspNetCompiler.TargetPath and Release.AspNetCompiler.TargetPath paths in the solution, but if I change them to be separate, the Debug one overrides the Release one when I next open the dialog.
When MSBuild starts building the project, it takes one or several project files. This dialog takes it parameters from MSBuild project file (you can edit it either from Visual Studio, or simply in every text editor). The project should have the property, called $(Configuration). You can use it in your output variable:
<OutputPath>E:\Projects\...\PrecompiledWeb\$(Configuration)\MyService</OutputPath>
One thing you must aware of is that the property $(Configuration) must be declared before the $(OutputPath) property.

TypeScript 0.9.* VisualStudio TS5037: Cannot compile external modules unless the '--module' flag is provided

I do get the TypeScript compiler error TS5037: Cannot compile external modules unless the '--module' flag is provided.
I am using TypeScript 0.9.1.1 und Visual Studio 2012.
Where can I set the --module option in Visual Studio?
Web Essential seems to no longer support this option in the dialog.
Thankx, Harry
Update:
I have a configuration file (config.ts) for my project. This file contains many statements as the following:
export var loggedInUserId: number = 0;
There are no other statements as the one before. Do I have to define a class or module around it?
I was having this problem in Visual Studio 2013, even with that setting above set correctly. It turns out there's a project-level setting as well. If you go to Project Settings on the project with TypeScript (highlight the project and type Alt+Enter), then go to the TypeScript Build tab, and select AMD under "Module System"
You can find the option for non project files here (Tools - options - Editor - TypeScript):
For my project based work I use grunt : https://github.com/basarat/grunt-ts

How do I pass this common property to MSBuild using TeamCity?

I am using the TeamCity Visual Studio runner. I want to add a setting that is not accessible from Visual Studio.
/Property:FileAlignment=4096
I typed that directly into the build step "Command line parameters." The build log shows the error:
MSBuild command line parameters contains "/property:" or "/p:" parameters. Please use Build Parameters instead.
I don't understand how to provide this to MSBuild from TeamCity and get rid of this warning!
1. Which kind of parameter should I use?
There are 3 kinds:
Configuration parameters
System properties
Environment variables.
I don't want an environment or system variable because I don't want this build to depend on anything external. I am going to try Config right now, but then I'm not sure I'm filling it in right.
2. How can I tell this parameter is actually getting used?
The build log, which seems only to have navigable/foldable xml-like levels with their program, did not say the build parameters.
You should use "System properties". Don't worry about the name, that's just how TeamCity calls it. They are regular properties. You can add them in "Edit Configuration Settings > 7. Build Parameters".
For example, you can add the system property as follows:
Name: system.FileAlignment
Type: System property (system.)
Value: 4096
Note that TeamCity will insist on the "system." prefix. It doesn't matter because the MSBuild script will still see it as $(FileAlignment).
The TeamCity documentation defines Build Parameters as "a convenient way of passing generic or environment-specific settings into the build script". Configuration parameters provide a way to override some settings in a build configuration inherited from a template. They are never passed to a build. System and Environment parameters are provided to your build script. Environment variables are actually set on the system (I can't find any documentation for this). System parameters are passed to the script engine.
TeamCity automatically provides System variables to the actual command line (it looks like the Visual Studio runner runs msbuild.exe and not devenv.exe). I guess that TeamCity is constructing a command like
cmd> msbuild.exe my-solution.sln /p:FileAlignment=4096
I tried this on my command line, just to make sure that it should work (I added the /v:diagnostic flag). The diagnostic verbosity makes msbuild print all of it's properties to the console. I verified that FileAlignment=4096 was in there.
That /FileAlignment property appears to be a special property that's automatically in any .csproj file. So you should be good to go. You can check the actual parameters that were passed to the build by clicking on any build and viewing the 'Build Parameters' tab. There's a section that shows the "Actual Parameters on Agent".
This was solved. To clarify, Anthony told how to solve the problem in the commandline using MSBuild. It can also be solved on the commandline using devenv, per a ticket with Microsoft, the syntax is:
devenv ..\..\mysolution.sln /Rebuild /Property:Config=Release;Platform=AnyCPU;Filealignment=512
What I wanted, however, was to get Teamcity's "Visual Studio Build" to accept the parameter. This was achieved as follows. In the box for Command line parameters, I entered:
/Property:FileAlignment=filealignment v:diag
Then the output tab for Build Parameters shows:
User Defined Parameters
Name Value passed to build
system.filealignment 512
system.verbosity diagnostic
(This is -754 chars for a comment so must be typed as a post)
hi Anthony, Thank you for replying!
Yes, msbuild on the commandline works fine for me as well and project files may store FileAlignment properties. In our case, upon discussion with Microsoft, it appears necessary that I specify the solution-wide aka build-wide alignment, ie in the command arguments, in addition to fixing the projects (which I have already done).
No parameter that I specify on the GUI item ( /Build Step / Command line parameters/ ) will appear on the tab /Build Parameters/. Of course some will not compile at all.
Also I have even more weird behavior where using
/verbosity:diagnostic
vs
/verbosity:minimal
causes a longer build log for the minimal! It appears diagnostic is hiding the details inside of a special task, which is part of Teamcity and not me;
[16:24:05]: Overriding target "SatelliteDllsProjectOutputGroup" in project "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets" with target "SatelliteDllsProjectOutputGroup" from project "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets".
I am struggling with this because the Teamcity-generated build output log is so nice to have as a TreeView. That works with the SLN build but using any bat file cannot produce log file with the pretty (xml, presumably) tree-format.
If you have further ideas I will love to hear them, and thank you for your edits! :)

MSBUILDEMITSOLUTION not working with .NET 4?

In prior versions of MSBuild, you could set an environment variable named MSBUILDEMITSOLUTION to 1 to get an XML version of a solution (.sln) file that could be parsed. According to the MSBuild Team Blog, that's still in the version that ships with Visual Studio 2010, but it does not seem to be working.
Has anyone managed to get this working with MSBuild 4.0? If so, what is required?
(We use this to find and run convention-based unit tests with an NAnt script.)
Set MSBuildEmitSolution=1 and then build from the command line. You should then see a MySolution.sln.metaproj file near MySolution.sln.
Notes:
If you open a command prompt window, then set the env var via System Settings, you will have to open a new command prompt.
You'd think you could also use msbuild /p:MSBuildEmitSolution=1, but you can't.