I am hoping to be able to use MSBuild to capture a subtree of files produced during the build of a project using Microsoft.NET.Sdk.Web and include them in deployment. So far, I have found that if I simply create the files inside the project folder before deployment, then it works but only for certain filetypes. DLLs, for instance, are excluded, presumably assumed to be non-content items. I have been poking around how the deployment stuff works, and have found the <ResolvedFileToPublish> element that I can put into <ItemGroup>, but I haven't figured out how it might be possible to employ this with wildcards. Specifically, I have a post-build step that places files into a folder deployment within the project, and I want all files in that subtree to be included in the package that is produced by /p:DeployOnBuild=true. How can I tack my files onto the deployment stage so that they're included in the ZIP even if they don't look like content items?
I have found a solution, in the form of adding a new <Task> set to run immediately after the internal tasks which collect files for publishing. This is not suitable for a long-term solution, since it ties to internal state, but this is a temporary fix and as such I think it's alright.
By adding this to the .csproj:
<Target Name="__CopyDeploymentToPublish" AfterTargets="_CopyResolvedFilesToPublishAlways">
<Exec Command="PowerShell.exe -Version 3.0 -ExecutionPolicy Unrestricted $(SolutionDir)deploy_webapp.ps1 -Source $(SolutionDir)src\IQ.Auth.OAuth2.Web -Target $(PublishDir)" />
</Target>
...my PowerShell script runs right after the standard deployment logic aggregates the files it intends to package up. I can at that point do whatever I want to the files and the way they're left is what'll end up in the ZIP file.
Related
Edit: Martin provides a link below to a defect, which is now fixed and released.
I am a university student. I would like to use .NET Core for my coursework. To do so, my code needs to compile and run on the department Linux cluster, because that is what my instructors test my submissions on.
My sysadmin installed the recently-released .NET Core 2.0 RHEL package for me on a trial basis. I created, built, and ran the sample CLI projects Microsoft provides, and they worked. But my sysadmin was displeased because dotnet created at least one file in (global) /tmp, which remained there after I logged off.
-rw------- myuser mygroup /tmp/.NETCoreApp,Version=v2.0.AssemblyAttributes.cs
In principle, he'd prefer dotnet not create any files in /tmp that it doesn't clean up when its process is done. More than that, when he tried to build Microsoft's samples himself, it failed; dotnet tried to access the above file, which his user did not have read permissions for!
Ideally, dotnet wouldn't create any files with a lifetime different from the project it is building. To achieve this, any such files could live in the project directory — maybe under the bin subdirectory, so that a clean will purge them. Is there a way to make dotnet write these files there instead? Otherwise, can it least use transient filenames, to avoid the permissions conflict we encountered?
Whatever the solution is, it has to be systemwide, and it cannot depend on the good behavior of users. So something like asking the user to set $TMPDIR will not work.
The easiest way would be to set the TMPDIR environment variable to a different location as MSBuild uses it to construct the path.
Another way to make msbuild use a local path for this file is to add a target like this to the csproj file:
<Target Name="SetTFMAssemblyAttributesPath"
BeforeTargets="GenerateTargetFrameworkMonikerAttribute">
<PropertyGroup>
<TargetFrameworkMonikerAssemblyAttributesPath>$(IntermediateOutputPath)$(TargetFrameworkMoniker).AssemblyAttributes$(DefaultLanguageSourceExtension)</TargetFrameworkMonikerAssemblyAttributesPath>
</PropertyGroup>
<ItemGroup>
<!-- GenerateTargetFrameworkMonikerAttribute doesn't add to #(FileWrites) for the global path -->
<FileWrites Include="$(TargetFrameworkMonikerAssemblyAttributesPath)" />
</ItemGroup>
</Target>
This will put it into the IntermediateOutputPath which is obj/{Debug/Release}/{TargetFramework}/. The added FileWrites item allows it to be cleaned on dotnet clean, which is not done for the global location to avoid race conditions during clean.
You can create a Directory.Build.targets file in your user directory / in the directory hierarchy your projects are in to wire up the target to all projects (unless they don't already contain a file with this name). Just surround the target with a <Project> element for this file.
There is a GitHub issue on changing the default location.
Recent libgit2sharp Nuget uses a new Nuget feature that allows you to include a piece of a build script in your NuGet. The purpose it to copy a native dll to a subfolder of the bin folder, like that:
<ItemGroup>
<None Include="$(MSBuildThisFileDirectory)\..\..\lib\net40\NativeBinaries\amd64\git2-e0902fb.dll">
<Link>NativeBinaries\amd64\git2-e0902fb.dll</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>...
Now, it was all nice and beautiful locally, but when I deployed it to AppHarbor, the native dlls appeared in the /bin folder (in addition to the target subfolder), which caused my app to fail.
The problem lies in the _CopyWebApplicationLegacy target, which does not execute locally (it's run only if you have a non-default output dir), thus I don't have this problem on my dev machine. Namely, it executes the following piece of code:
<!-- Copy items that have been marked to be copied to the bin folder -->
<Copy SourceFiles="#(_SourceItemsToCopyToOutputDirectory)"
DestinationFolder="$(WebProjectOutputDir)\bin"
SkipUnchangedFiles="true"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"/>
You can see that the target folder is always /bin -- I believe it's a bug in the Microsoft.WebApplication.targets file (I can't control it on the target machine).
Is there a simple fix, or should I revert to a script in the PostBuild event (which I'll have to update with each new version)?
As mentioned here: https://github.com/libgit2/libgit2sharp/issues/1089#issuecomment-111000722
the way AppHarbor is building your project, it's triggering the old _CopyWebApplicationLegacy target, and that is basically broken. It messes up all files that are using the Copy to Output Directory property by putting them directly into the output directory instead of respecting the relative folder structure. It also doesn't run any web.config transforms you may have.
You can make your project use the newer _CopyWebApplication target instead by adding the following to your project file:
<UseWPP_CopyWebApplication>True</UseWPP_CopyWebApplication>
<PipelineDependsOnBuild>False</PipelineDependsOnBuild>
The thing I'm not sure about is if AppHarbor has some reason why they wouldn't want you to use the newer copy target instead of the old broken one.
Problem
As part of my csproj I have a custom MSBuild task that executes the YUICompressor and generates a compiled css and js file.
<PropertyGroup>
<CssOutputFile>$(OutDir)..\Styles\compiled.css</CssOutputFile>
<JavaScriptOutputFile>$(OutDir)..\Scripts\compiled.js</JavaScriptOutputFile>
<BuildDependsOn Condition="'$(Configuration)' != 'Debug'">
$(BuildDependsOn);
CompressorTarget;
</BuildDependsOn>
</PropertyGroup>
This runs fine as part of the git deployment and the file is being generated, however the Azure Web Sites deployment engine will then copy all the output files to another folder. In that process it seems it takes whatever you have in your csproj instead of whatever you have in the folder. That menas that the generated compiled.css and compiled.js won't be copied (because they are not in my csproj)
What Azure does to deploy your project should be exactly the same as if you do the following:
Right click on the project and choose Publish
Change the Publish Method to 'File System'
Enter a path and click Publish
So generally, you'll want to make sure that your build process works such that you get the right file when you do this local publish. If it does, then chances are you'll get the same results when git pushing to Azure.
The workaround I used for now is adding an empty compiled.css and .js file to the csproj and I wanted to write this question in case someone goes through the same thing.
It would be great if someone from MS can comment if there are plans on doing something different for this scenario.
Depending on where you place the compiled scripts, you can use star-includes in your project file:
<ItemGroup>
<Content Include="assets\**\*" />
</ItemGroup>
If Azure uses your project file to determine what gets deployed (which seems somewhat strange to start with), then that should work.
I need to collect into a single folder all test assemblies, with their dependencies, and configuration files. The process should preserve the directory structure from the output of each test project. We have a solution that requires manually attaching test projects to a master project, but our solution has far too many projects for this to be maintainable. These should be located automatically based on naming convention (x.UnitTest.csproj, y.IntegrationTest.csproj).
For background, we are working with a build system that passes artifacts (binaries, etc) between agents. We are compiling on one agent, and testing on other agents. The massive duplication of assemblies between test projects is slowing the build process down.
What I have done:
1) I have a csproj that references most of the test projects. This gets binaries and dependencies into one folder.
2) I am able to identify all files to copy using this
<CreateItem
Include="%(ProjectReference.RootDir)%(ProjectReference.Directory)$(OutDir)*.config">
<Output TaskParameter="Include" ItemName="TestConfigurationFiles"/>
</CreateItem>
<Copy
SourceFiles="#(TestConfigurationFiles)"
DestinationFolder="$(OutDir)">
</Copy>
I've attempted most obvious things, such as
MsBuild task: RebaseOutputs attribute, overriding the OutDir property. I can provide the msbuild task with a dynamically generated set of outputs, but can only build them in their default folder.
Hooking into the TargetOutputs of
msbuild task gives only the primary
output assembly (without
dependencies).
I experimented with "Copy Always" for
configuration files. This puts them
in the output directory of the
dependent project as "app.config" not
"dllname.config", and not in the
final project.
Solutions that could make this better might include
Provide an example of adding to the projectreference item array dynamically, before compilation.
Use msbuild TargetOutputs to create a list of all files in the folder (instead of just the primary output) and copy to a destination folder.
Today I'm using msbuild 3.5. Ideally the solution would work with msbuild 3.5. We are transitioning to .NET 4 / MsBuild 4 soon, so, if must be done in .Net 4, that is fine.
Have you considered flattening the folder structure when you export your artifacts?
Something like:
src/*.UnitTest*/bin/**/*.* -> /testlibs
src/*.IntegrationTest*/bin/**/*.* -> /testlibs
Elsewhere on the Web, you can find recommendations on using something like this to simulate the Publish feature in the VS 2005-2008 IDE from a command-line (I hope I did not goof up the syntax!):
msbuild /t:ResolveReferences;_CopyWebApplication /p:BuildingProject=true;OutDir=C:\inetpub\wwwroot\ blah.csproj
Now, it looks like the .dll's copy fine. However, there are certain configuration files and template files that are copied to the bin folder which are needed for the app to work. For example, an NHibernate configuration file shows up in blah.csproj as:
<None Include="blah.cfg.xml">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
While using Publish from within the IDE copies this file as it should, the aforementioned _CopyWebApplication target does not. I need this file to be copied in the build script. Is this desired behavior for _CopyWebApplication? Any recommendations on how to fix this?
EDIT 4/21/2010:
Let me clarify that we are limited (for now) to VS 2005 and VS 2008 projects, and that our build scripts are written for MSBuild 3.x. We are not yet ready to move to VS 2010.
Let me also specify that we are looking for a solution available from within a command line so that we can automate a Publish-like command along with custom build options, and possibly automate deployments down the road.
This is just a workaround.
In the build script for publishing Web sites, after running MSBuild on the Web project itself to publish it (Targets="ResolveReferences;_CopyWebApplication"), I added a copy operation:
<Copy SourceFiles="#(ProjectBinFiles)" DestinationFolder="$(StageBin)\%(ProjectBinFiles.RecursiveDir)" />
where ProjectBinFiles is an Item representing the files in the bin directory in the source directory, and StageBin is a Property representing the bin folder in the published site's directory. So far, it seems to work.
I was having a similar issue as well. I think the answer is using MSDeploy. Investigating it now, but may provide functionality required...
I had this same issue in VS 2012 and eventually fixed it by doing the following to any files which needed to be copied:
Set the Copy to Output file property to Copy if newer
Set the Build Action file property to Content (or Compile if the file needs to be compiled)