Is there a way to globally set the CurrentDirectory to the test assembly's directory? Like a config file?
You can set the current directory the same way as you would in normal c# code. e.g.
Directory.SetCurrentDirectory(dir);
If you want to make sure this happens before any of your tests are run, do this in a SetUpFixture outside of any namespace.
Related
I have a winforms app, which is deployed via click-once publishing.
Assuming my tests are correct, the only way to have this same app installed more than once in the same machine, is the each publish be made for a different Assembly Name.
My problem is that I am running the msbuild via jenkins, and, to accomplish the above, I would add /p:AssemblyName={whatever}, which will rename all assemblies generated by the build to this same {whatever} value. If the output of my build is 1 exe and 5 dlls, all 6 files will be named {whatever}.
Which in turn raises CS1704: An assembly with the same simple name {whatever} has already been imported.
Is the only way out of this to perform all csc.exe calls that msbuild generates, myself, and see if I can set different assembly names per project ?
Or are there other ways to solve this ?
The problem here is that every property passed to MSBuild as a command line argument is considered a global property and will override the property on all projects built in that invocation. The solution is to introduce an intermediate property that only the "main" project consumes.
Edit the app's csproj file to include this (in the place where AssemblyName is already defined - assuming here that WindowsFormsApp1 is the name of the application):
<AssemblyName>WindowsFormsApp1</AssemblyName>
<AssemblyName Condition="'$(OverrideAssemblyName)' != ''">$(OverrideAssemblyName)</AssemblyName>
you can then use the msbuild commands using /p:OverrideAssemblyName=AnotherName without creating conflicting assembly names on referenced libraries. The property is still defined globally, but only one project consumes it.
When using the new SDK style csproj format, it is possible to use a <targetframeworks> element for a semicolon-separated list of target frameworks to build the project for.
This results in one subfolder per target framework in the build output folder:
However, when passing the OutDir property on the msbuild command line, it does NOT create the subfolders, and the built assemblies are all placed in the same folder.
Command line that works, but doesn't allow output location:
msbuild projectfile.csproj
Command line that selects output directory, but places built assemblies in same folder (effectively overwriting the target framework assemblies that are built first):
msbuild projectfile.csproj /p:OutDir=buildtemp
Is there a way to place the build output in a non-default folder while still retaining the targetframwork subfolders?
The property that is now used is OutputPath, however setting it from the CLI makes it a global property and overrules the automatic appending of the output path. The workaround is to make an intermediate property that is global and consume it from the project.
Add this to your project file inside a PropertyGroup:
<OutputPath>$(BaseOutputPath)</OutputPath>
Then you can set this property globally when calling the build command:
martin.ullrich#martins-imac:~/tmp$ dotnet build /p:BaseOutputPath=bin/foo
tmp -> /Users/martin.ullrich/tmp/bin/foo/netstandard1.4/tmp.dll
tmp -> /Users/martin.ullrich/tmp/bin/foo/netstandard1.6/tmp.dll
The problem here is that the SDK tries to change the OutputPath property based on TargetFramework and AppendTargetFrameworkToOutputPath. But if the value is specified via CLI, the project logic cannot overwrite it.
Also note that BaseOutputPath is actually used in the SDK defaults (defaulted to bin\), but it will try to append the configuration name by default..
I'm calling an external tool to do some post processing in my build sequence using the Exec task in MSBuild. When I update the tool to a new version the name of the directory of the executable changes, but the directory is added to the system PATH variable. Is it possible to use the system PATH variable in MSBuild? I tried the following code but it does not work:
<Exec Command=""$(PATH)\mytool.exe" />
If the directory has been added to the PATH variable, I would expect that the file path would be resolved automatically. I.e. you should be able to use:
<Exec Command="mytool.exe"/>
Maybe first check if the resolution is working ok by opening up a command prompt, cd'ing to some root directory that is different to where the 'mytool.exe' lives, and see if it is resolved when you simply enter "mytool.exe" at the prompt.
We have many standard .vcxproj files that we use MSBuild to build. For certain properties and targets we need a .vcxproj.user file to override the properties that are specific to the build in progress.
In order to use the same build process in the development environment as the build machine, we'd like to specify the path to the .vcxproj.user as a different directory to the .vcxproj file, so the build process can generate the file it needs in a separate directory without disturbing the user's own settings.
I've found very little documentation on where msbuild looks for the .user file, or if it is even possible to specify the path?
Path *.user file for cpp projects is specified in C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.Cpp.Default.props
<MSBuildAllProjects Condition="Exists('$(MSBuildProjectFullPath).user')">$(MSBuildAllProjects);$(MSBuildProjectFullPath).user</MSBuildAllProjects>
It is intended to specify custom user settings (for example you can specify app to run in debug) and couldn't be changed.
To change build process you can use CustomBeforeMicrosoftCommonTargets. You can create your own *.targets file which will imports special properties/targets, change build process to make some preprocessing actions and so on. I've wrote an example for AfterTargets here. All you need is to implement custom build logic and change registration to BeforeTargets.
I want MSBuild to build WIX 3.5 project containing static files and binaries from another project's output folder. While with static files it all works just fine: I just set Source attribute of File element to "..\AnotherProject\Static\StaticFile.ext", I can't reference binaries, because they aren't in "..\AnotherProject\bin\Release\" folder, they're in MSBuild output folder which I don't know how to reference.
The only way to do so is set some variable in .wixproj file in for Release build configuration and then use it, but it seems wrong. What do I miss?
You want "bind paths". The documentation isn't great about this but you can specify BindInputPaths on the Light MSBuild Task. Any File/#Source or #SourceFile that starts with "SourceDir\" or is a relative path (doesn't start with an "X:\" or "\") will be searched in those bind paths. You can use MSBuild variables to get the BindInputPaths set correctly.
Tried $(var.Web.TargetDir) - working.