I'm using the Wix HeatFile task in a post build step
<HeatFile OutputFile="Interop.dll.wxs" File="..\Interop\bin\x86\$(Configuration)\Interop.dll" DirectoryRefId="INSTALLDIR" ComponentGroupName="Interop_Dll" AutogenerateGuids="true" SuppressFragments="true" SuppressRootDirectory="true" ToolPath="$(WixToolPath)" PreprocessorVariable="var.InteropBinDir" />
Once I do a build, it locks my dll and subsequent builds fail with:
Error 6 Unable to copy file "obj\x86\Debug\Interop.dll" to "bin\x86\Debug\dll". The process cannot access the file 'bin\x86\Debug\Interop.dll' because it is being used by another process. Interop
until I restart Visual Studio.
How can I stop the Wix task from causing this problem?
It seems that this property for the heat task solves your problem:
RunAsSeparateProcess="true"
I had the same problem with HeatDirectory tasks, and it worked for me. Solution was taken from http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Locked-DLL-files-when-using-WiX-HeatDirectory-MSBuild-tasks-td6015042.html
Related
I have the following problem and I'm surprised that I can't find any straightforward solution on SO or MSDN.
I have existing *.pubxml profiles in several of my web applications and I would like to execute post deployment script - powershell script - which reorganizes WebSite and its child applications slightly.
I'm not usign Web Deployment Package - just Web Deploy.
The script is deployed successfully but the problem is - how should I execute it automatically after deployment?
I have two scenarios:
Execute by simply "Publish..." from Visual Studio.
Execute as part of TFS Build definition (TFS 2013).
You can try to define a “Target” by MSBuild to achieve your requirement.
For the first scenario:
The Visual Studio build process is defined by a series of MSBuild .targets files that are imported into your project file. One of these imported files, Microsoft.Common.targets. This file contains a set of predefined empty targets that are called before and after some of the major targets in the build process.
So you can define a "Target" element whose "AfterTarget" attribute's value is set to "MSDeployPublish":
<Target Name="CustomPostPublishActions" AfterTargets="MSDeployPublish" >
<Exec Command="..\PostDeploymentScript.sp1 " />
</Target>
For the second scenario:
You can add a PowerShell build task as MrHinsh`s suggestion.
You should switch to deploying from Build & Release only in VSTS/TFS.
You can then add a PowerShell build task and either point at a script or use Inline if it's short. If it is a script that you use in many builds you might want to write your own build task.
When Gulp task is bound to 'project open', the task will be started again and again if the project file get changed. So we end up having multiple running instances of the same task.
How to get around this so that the runner recognizes that the task is already running and won't start it again on project open binding?
Just to be clear the VS Task Runner is not the greatest thing in the world. It is super sensitive to specific settings and malfunctions at will without changing anything.
With that said bind the task to "Before Build", and not to "Project Open". I'm guessing that you are doing that in order to install npm, or bower packages since that is a task that you don't want to run on every build.
All in all, save yourself a few hours of headache after headache and use the command line outside of Visual Studio. If you are on Windows and you don't like the prompt, I don't either. It sucks. And that's an understatement.
Use Cmdr and love the prompt again.
I have inherited a WiX project from a contractor that recently left.
When I build the WiX installer project, there is no problem - the .msi is built and output as expected.
But when I "rebuild" the WiX installer project, again the .msi is built just fine by light.exe, but it subsequently gets deleted by a "CoreClean".
Further info: The wix project packages (and references) a single web project.
This is a snippet of the output:
ICE105: ICE105 - Validates the package to make sure that it can be installed in true Per-User mode
ICE105: Created 05/01/2008. Last Modified 05/21/2008.
Laying out media.
Moving file 'C:\Users\codemonkey\AppData\Local\Temp\nxkfdvui\AmazonWebsiteInstaller.msi' to 'C:\web\main\Amazon.Webby.Install\bin\Release\AmazonWebsiteInstaller.msi'.
Done executing task "Light".
...
...
Target "CoreClean" in file "C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets" from project "C:\web\main\Amazon.Webby.Install\Amazon.Webby.Install.wixproj" (target "Clean" depends on it):
Task "ReadLinesFromFile"
Done executing task "ReadLinesFromFile".
Task "FindUnderPath"
Comparison path is "bin\Release\".
Done executing task "FindUnderPath".
Task "FindUnderPath"
Comparison path is "obj\Release\".
Done executing task "FindUnderPath".
Task "Delete"
Deleting file "C:\web\main\Amazon.Webby.Install\bin\Release\AmazonWebsiteInstaller.msi".
Deleting file "C:\web\main\Amazon.Webby.Install\bin\Release\AmazonWebsiteInstaller.wixpdb".
Deleting file "obj\Release\MainWixComponents.wixobj".
Deleting file "obj\Release\UploadContent.wixobj".
Deleting file "obj\Release\WebSiteContent.wixobj".
Deleting file "obj\Release\Product.Generated.wixobj".
Done executing task "Delete".
...
...
I can't find any delete task in the installer project file that involve the msi or output folder, so it's a result of visual studio doing a rebuild and thinking it needs to clean out files that it doesn't.
This seems to be the relevant section in "C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets" causing the delete of the newly built msi:
<!--
==================================================================================================
CoreClean
Cleans all of the compile and link outputs as well as any intermediate files generated along
the way.
==================================================================================================
-->
<PropertyGroup>
<CoreCleanDependsOn></CoreCleanDependsOn>
</PropertyGroup>
<Target
Name="CoreClean"
DependsOnTargets="$(CoreCleanDependsOn)">
...
<!-- Delete those files. -->
<Delete Files="#(_CleanPriorFileWritesInOutput);#(_CleanPriorFileWritesInIntermediate)" TreatErrorsAsWarnings="true">
<Output TaskParameter="DeletedFiles" ItemName="_CleanPriorFileWritesDeleted" />
</Delete>
...
Any ideas?
Thanks.
I know it's old but this is mentioned as a fixed bug in SourceForge:
http://sourceforge.net/tracker/?func=detail&atid=642714&aid=1719357&group_id=105970
Are you using a version post 3.0.4102.0?
There does seem to be some debate as to whether the bug is really fixed in the comments.
To resolve this I took all the InitialTargets steps (which were msbuild.exe calls) out of the wixproj file and moved them into a batch script called from the pre-build event project property. I did this because there was another problem - the targeted projects were being built as the project was loaded, which meant that it took a long time to open the solution. At any rate, moving everything into a batch file resolved both problems.
I have a custom MSBuild task which among other things adds embedded resources to other projects in the solution. After adding the resources I'd like to then build those projects, but found I can't get this working within Visual Studio.
To test, I stripped out the custom task entirely and redefined a simple AfterBuild target in the web project of a Silverlight solution. The target uses the MSBuild task to build the Silverlight application project in the solution, and looks like this:
<Target Name="AfterBuild">
<PropertyGroup>
<LinkedProject>..\SilverlightApplication1\SilverlightApplication1.csproj</LinkedProject>
</PropertyGroup>
<MSBuild Condition="'$(LinkedProject)' != '' "
Projects="$(LinkedProject)"
Targets="Build"
Properties="CustomFlag=true" >
</MSBuild>
</Target>
The odd thing is that this works perfectly when using MSBuild from the command line, yet does not work in Visual Studio when building the web project. I thought this might be some sort of Silverlight problem, and had the task build a .NET class library project instead, but the result was the same - it worked from the command line but not within VS. In VS there's no actual error - it's just that the Csc task does not compile the assembly and generates no output.
What do I need to do to get this working within Visual Studio?
Pass the 'UseHostCompilerIfAvailable=false' property to the MSBuild task.
It looks like Visual Studio breaks badly if csc is invoked from a MSBuild task as it reuses the initial project build settings for its in-process host compiler. In my case, I was building the same project twice - default build was using target framework v3.5, with a AfterBuild MSBuild task specifying v4.0. I ended up with the same issue - csc appeared to run but produced no output. I think what was happening was that with the UseHostCompilerIfAvailable property set to true, csc was calling the hosted compiler which reused my initial project settings, so even though the command line showed csc "building" my v4.0 assembly, the host compiler was simply overwriting the v3.5 one I had just built!
Change Visual Studio verbosity to detailed and check build log. I think that CoreBuild is not executed if your files have not changed, so you could try to use AfterCompile instead of AfterBuild.
I am trying to automatically publish and deploy my .Net 4 web application automatically from a build script to be run by our continuous integration server. I am using the new _WPPCopyWebApplication target from VS2010 to perform the publish, however it appears to reset the current working directory of the msbuild project to c:\ this causes my prebuild steps to fail as they have relative paths to some external tools. The task I am running from our master.build file is as follows:
<Target Name="PublishWeb">
<MSBuild
Projects="$(ProjectPath)"
Targets="ResolveReferences;_WPPCopyWebApplication"
Properties="WebProjectOutputDir=$(DeployPath);OutDir=$(TempOutputFolder)$(WebOutputFolder)\;OutputPath=$(ProjectPath)\bin\Debug;" />
</Target>
This does not happen when using the legacy _CopyWebApplication. Does anyone have any idea how to resolve this problem?
Two possibilities come to mind:
Use the Exec task to call msbuild.exe, and supply a specific working directory.
Your pre-build steps are evaluated by MSBuild and can reference any MSBuild property, so make your paths relative to something specific, like $(MSBuildProjectDirectory), or $(MSBuildThisFileDirectory), instead of just relative to the current directory.