i'm on Visual Studio 2012 and i use wix
I wanted to use a WixVariables or a DefineConstants on Target After build (wixproj) when i unload the project
i used on
<DefineConstants>VersionNodeServer=0.0.1;</DefineConstants>
Or
<WixVariables>VersionNodeServer=0.0.1;</WixVariables>
but when i used this variable 'VersionNodeServer' like that
<Target Name="AfterBuild">
<WebDownload FileName="test.msm" FileUri="$(VersionNodeServer)"/>
the build failed because FileUri is empty.
i saw my variable on the VS console ..
C:\Program Files\WiX Toolset v3.10\bin\candle.exe -dDebug
-dVersionNodeServer=0.0.1;[...]
Neither <DefineConstants> nor <WixVariable> define a variable for MSBUILD. You have to put
<PropertyGroup>
<VersionNodeServer>0.1.1</VersionNodeServer>
</PropertyGroup>
somewhere in your .wixproj file.
Related
I'm trying to compile Python 2.7 with clang on Windows. I thought a solution to doing this would be to specify the properties CLToolPath and CLToolExe. However, when I set these properties in the project files, msbuild seems to just ignore them and continue using the Microsoft compiler.
The weird thing is that when I specify those properties on the command line, msbuild does actually pick them up. (But due to other aspects of the way Python 2.7 is set up, the build doesn't actually succeed that way, so it doesn't solve the problem. It just proves these are the right properties.)
This is the relevant section of a project file
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<Midl>
<TargetEnvironment>X64</TargetEnvironment>
</Midl>
<Link>
<SubSystem>Console</SubSystem>
</Link>
<ClCompile>
<CLToolPath>C:\llvm\build\Release\bin</CLToolPath>
<CLToolExe>clang-cl.exe</CLToolExe>
</ClCompile>
</ItemDefinitionGroup>
And this is the command line I'm using
msbuild /t:clean,build /p:Configuration=Release /p:TrackFileAccess=false /p:Platform="x64" /fileLogger pcbuild.sln
Any idea what could be causing the properties to be ignored?
You're putting it to a wrong place. Find relevant PropertyGroup tag and add <CLToolExe> and <CLToolExe> to it as follows:
<PropertyGroup>
<CLToolExe>clang-cl.exe</CLToolExe>
<CLToolPath>C:\llvm\build\Release\bin</CLToolPath>
</PropertyGroup>
I have added some variable to PATH, such as
set resultPath=C:\Temp\Results
set platform=x64
And I want to use this variable in microsoft test configuration file .runsettings. e.g.
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<RunConfiguration>
<ResultsDirectory>$(resultPath)</ResultsDirectory>
<TargetPlatform>$(platform)</TargetPlatform>
</RunConfiguration>
</RunSettings>
I tried both mstest.exes and vstest.console.exe by using configuration .runsettings file as above, but failed. The .trx file was created under .\$(resultpath) folder and one of test cases failed because it need x64 environment binaries to run, the default platform of microsoft test is win32.
Any comment?
My OS is win7, Visual studio 2012.
This isn't currently supported but you can vote for it at https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/7491553-unit-test-configuration-file-runsettings-support
I want to change name of executable file. Like suppose my project name is "SampleDemo" It will create executable file Like 'SampleDemo.exe' but I want to rename it to 'Demo.exe'
Open the Project Properties in Visual Studio (right click on project in Solution Explorer and select "Properties" from popup menu)
On the "Application" tab of the properties window, change the "Assembly name"
If like me you wanted to change the output file name without changing the assembly name, put this like in your .csproj's main <PropertyGroup>:
<TargetName>Desired output name without extension</TargetName>
By MsBuild:
<Target Name="Rename" AfterTargets="AfterBuild">
<Move SourceFiles="$(OUTDIR)\Application1.exe" DestinationFiles="$(OUTDIR)\ApplicationNew.exe" />
<Message Text="Renamed executable file." Importance="high" />
</Target>
Change ApplicationName is not best way.
For example if you used wpf resources, full path contains ApplicationName and after renaming executable file you need to change all full pathes in out application
<ResourceDictionary Source="pack://application:,,,/Application1;component/Themes/CustomStyles.xaml"/>
In this situation I used msbuild.
For me none of the answers worked in net6.
In my csproj file:
<PropertyGroup>
<AssemblyName>MyCustomExecutableName</AssemblyName>
</PropertyGroup>
Tested in Net6, Windows. Using VS Code and buiding with dotnet run.
This will change both the executable name and the dll file name.
"Post-build event command line" in Build Events tab, would be an option.
You can use:
copy $(TargetPath) $(TargetDir)demo.exe /Y
or
ren $(TargetPath) $(TargetDir)demo.exe /Y
Double Click 'My Project'
Click 'Package Manifest...'
Click 'Application'
Under 'Display Name' fill in the name you want your exe to be called.
In your case it would be: 'Demo'
since you want the project name 'SampleDemo' to have an output exe named 'Demo'
We have a solution that we would like built against two architectures (x86 and x64) and put in the same folder on build. The solution has four projects, three of which we are outputting as AnyCPU, since they are called by the fourth project and thus will take on whatever bitness it is running under.
I have already gone into the csproj file and changed it like so:
<Choose>
<When Condition=" '$(Platform)'=='x64' ">
<PropertyGroup>
<AssemblyName>TaskLoaderHost64</AssemblyName>
</PropertyGroup>
</When>
<When Condition=" '$(Platform)'=='x86' ">
<PropertyGroup>
<AssemblyName>TaskLoaderHost32</AssemblyName>
</PropertyGroup>
</When>
</Choose>
Additionally I set the OutputPath for all cominations of Platform and Configuration to \bin\Debug or \bin\Release (removing the architecture portion). When building in Visual Studio, I set Architecture to x86, build taskloaderhost project, set to x64, build, and in the bin\debug folder I have one copy each of the three AnyCPU project outputs and one each of x86 and x64 TaskLoaderHost outputs. This is exactly what I want. Everything in the same folder.
Moving this to TFS, I created a Build Definition that builds the TaskLoaderHost project in both x86 and x64 flavors. And instead of the above, I get the following at the drop location root.
\
\logs
\x64
\x64\Debug
\x86
\x86\Debug
Where did the extra directories come from? Specifying OutDir in MSBuildArguments does nothing, and TFS seems to ignore the OutputPath property (but it does read the Assembly Name property) from the csproj file.
Anyone know a way to force it to put output from two different architectures in the same directory?
Interesting Fact
If you do not specify OutputPath in the project file, TFS complains about the fact that it is undefined, and refuses to output it. If you do specify it, TFS does not use that value in the Drop location filesystem structure.
I found the following article on MSDN that describes how this can be done, and I have it working on my TFS Build Server. It is written against TFS 2010, but works well enough for 2012 as well.
Control Where the Build System Places Your Binaries
Essentially what you do is edit the BuildTemplate and Project definitions (csproj/vbproj/etc) that are being built.
In the Build Template, edit the Run MSBuild found at this location:
Process > Sequence > Run On Agent > Try Compile Test and Associate Changesets and Work Items> Sequence > Compile, Test, and Associate Changesets and Work Items > Try Compile and Test > Compile and Test > For Each Configuration in BuildSettings.PlatformConfigurations > Compile and Test for configuration > If BuildSettings.HasProjectsToBuild > For Each Project in BuildSettings.ProjectsToBuild > Try to Compile the Project > Compile the Project > Run MSBuild for Project.
Remove the value in the OutDir property, and put the following into the CommandLineArguments property: String.Format("/p:SkipInvalidConfigurations=true;TeamBuildOutDir=""{0}"" {1}",
BinariesDirectory, MSBuildArguments)
Finally place the following after the other conditional property groups in your Project file:
<PropertyGroup Condition="$(TeamBuildOutDir) != '' ">
<OutputPath>$(TeamBuildOutDir)\$(SolutionName)\$(MSBuildProjectName)\$(Configuration)</OutputPath>
</PropertyGroup>
I changed the OutputPath on mine a little. Since I am building a single project which has the other projects as dependencies, I only had to put the above PropertyGroup in a single project file.
I am developing a tool which will automate the installshield (2008 Primer Version) setup (project type InstallScript MSI). The input files have been referenced directly from the Drop Location which will copy all the files after build that from Team Foundation Server (TFS).
Next from batch file i am calling the ISCmdBld.exe which will build the Installshield project through command line.
When i initiated the build i came across that file versions are older in Installshield editor as well as in Release Folder, where as in Drop Location of TFS it is latest version. How do i refresh the File list of Installshield programmatically or is there any solution available.
Thanks
It sounds like you may have set hard references to a drop folder whose path changes with every build.
In our builds, I map a W:\ drive to our current drop folder using the following command:
<!-- Map the W drive to the current drop's release folder -->
<Exec Command=""c:\pstools\psexec.exe" -s -accepteula subst w: "$(DropLocation)\$(BuildNumber)\Release"" ContinueOnError="false" />
Then, I went into my install project and under the Path Variables view, I changed the reference path to W.
This requires PsExec, which is a free utility from Microsoft: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
At the end of the build, I unmap the W drive, so the next build can run without an error:
<Exec Command=""c:\pstools\psexec.exe" -s -accepteula subst w: /D" ContinueOnError="true" />