I have some xaps being built by other projects in my solution and I need the xaps to be included in the resulting WSP.
I have a mapped folder Layouts with a sub-folder ClientBin and then in the csproj I have the following:
<ItemGroup>
...
<Folder Include="Layouts\ClientBin\" />
...
<Content Include="Layouts\ClientBin\*.xap" />
</ItemGroup>
...
<Target Name="BeforeLayout">
<ItemGroup>
<XAPFiles Include="..\..\out\$(Configuration)\bin\sl\xap\**\*.xap" />
</ItemGroup>
<Copy SourceFiles="#(XAPFiles)" DestinationFolder="Layouts\ClientBin" OverwriteReadOnlyFiles="true" />
</Target>
When I delete the xaps from the destination folder and open the SP project in VS the package manager shows the layouts folder with nothing in it. And then when I build none of the xaps get packaged in the WSP but the copy operation worked local to the project. If I rebuild nothing changes. If I unload and reload the project then build, the WSP does contain the files I need.
This works for my dev box because I can make sure I'm performing all these steps to keep the package manager happy, but it doesn't work on the team build machine. Are there steps I can take to make sure the package manager grabs those xaps or even other ways to achieve what I'm trying to do?
I created empty placeholders in Layouts\ClientBin for all the xaps to be copied.
This wasn't optimal since it required some manual dependency management, but it works.
The end result is that the package manager is aware of those files existing when you open the project in VS and that they need to be packaged up into the WSP. The copy operation works as before but now the new files are packaged.
Related
I'm deploying a WebJob to Azure using Visual Studio, but none of the subdirectories in the build output folder of the project are copied to Azure (as per looking in the FTP folder and by virtue of the app not executing correctly). Is there any way to get the deploy to copy all the files and folders across?
More info: the subdirectories are from a referenced project and the files do have "Copy Always" set. They do appear in the output build directory of the WebJob project
UPDATE:
So it seems that at some point this was fixed and now works as expected
I hacked together an automated deployment that seems to be work so far:
Add your WebJob project as a build dependency to your website project
I deploy my WebJob to a standalone Azure Website, so the website didn't reference the project directly. I don't want the build output of the WebJob project included in the bin of the website, just the proper app_data path. If you're not worried about MSBuild compatibility, you can set the build dependency using Visual Studio. Or you can edit the website project and add a reference with the other <Reference> tags:
<ProjectReference Include="..\PathToJobs\Jobs.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
On PostBuild, copy the WebJob bin output to the magic app_data folder
WebJobs are expected to be in app_data\jobs\[type]\[name], so we copy the WebJob bin to the that folder in the website project:
set webjob_dist_path=$(ProjectDir)app_data\jobs\continuous\Job
IF EXIST "%webjob_dist_path%" (
RMDIR "%webjob_dist_path" /S /Q
)
XCOPY "$(SolutionDir)Jobs\bin\$(ConfigurationName)\*" "%webjob_dist_path" /Q /E /I /Y
Tell the website to include the WebJob magic folder when it deploys
(see: How do you include additional files using VS2010 web deployment packages?)
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>
CustomCollectFiles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>
<CopyAllFilesToSingleFolderForMsdeployDependsOn>
CustomCollectFiles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForMsdeployDependsOn>
</PropertyGroup>
<Target Name="CustomCollectFiles">
<ItemGroup>
<_CustomFiles Include="app_data\jobs\**\*" />
<FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
<DestinationRelativePath>%(RelativeDir)%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
Deploy the website using the normal Azure Publish profiles. Done!
Thank you for reporting this. It looks like a bug in the tooling. I filed a bug for it.
I have a solution with several projects in it with dependencies.
When I build the web site project, the bin folder contains a number of sub folders
Some from AjaxControlToolkit.dll, some from folders generated by dependency projects.
I also get the PDB files generated and copied into the bin folder.
Everything works
If I do a publish using the context menu (publish to file system)
I get the same files generated
Everything works
When I do a web publish using msbuild
I do NOT get the PDB files for the dependencies (but do for the web site)
I do NOT get the folders copied into the bin folder
This breaks a lot of stuff.
I do the MSBuild in 2 steps
1 -> compile in source directory
At this point, all files and folders are present in the source bin folder
2 -> publish to a new folder
At this point the dependent files and folders are not transferred across.
From further investigation:
obj\Release\Package\PackageTmp\bin in the project does NOT contain the files
obj\Release\CustomerPortal.csproj.FileListAbsolute.txt DOES list the files
Batch File
SET MSBuild="C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe"
SET targetFolder=C:\Temp\Customer_Build
SET configuration=Release
%MSBUILD% "%targetBuildFolder%\Customer.CustomerPortal.sln" /t:Build /p:Configuration=%configuration%;BuildProjectReferences=true;Platform="Any CPU" >> "%targetFolder%\build_all.log"
%MSBUILD% "%targetBuildFolder%\CustomerPortal\CustomerPortal.csproj" /t:WebPublish /p:PublishUrl=%targetBuildFolder%\_B_MyCustomer\;VisualStudioVersion=11.0;WebPublishMethod=FileSystem;Configuration=%configuration%;BuildProjectReferences=true;DeployOnBuild=True;PackageAsSingleFile=False;PrecompileBeforePublish=False;ExcludeGeneratedDebugSymbol=False;Platform="AnyCPU" >> "%targetFolder%\build_all.log"
Publish Profile XML
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Debug</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>True</ExcludeApp_Data>
<publishUrl>C:\Temp\Customer_Build\Deploy\MyCustomer</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
</PropertyGroup>
</Project>
Does anyone know a way that I can either:
1. Specify a command line option that will allow the same behaviour for MSBUILD as the profile does
or
2. Use the profile, but be able to override the publish folder and configuration
In the Visual Studio 2012 Build menu, there's a Publish command. In this you can establish profiles which are saved as .pubxml files in the Properties folder of the Project. I have one such profile that's a simple file copy operation - it just compiles the site and dumps it to a folder.
How can I use msbuild at the command line to publish a compiled web application to a folder?
What I've tried
I've tried the example from this question:
After Publish event in Visual Studio
And the changes and examples given here:
http://www.digitallycreated.net/Blog/59/locally-publishing-a-vs2010-asp.net-web-application-using-msbuild
The latter seems to get closest, but it causes every library Project the .csproj I'm attempting to publish from to throw an error:
Project "MainProj.csproj" (1) is building "ReferencedProj.csproj" (2) on node 1 (default targets).
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(609,5): error : The OutputPath property is not set for project 'ReferencedProj.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Staging' Platform='AnyCPU'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [ReferencedProj.csproj]
Done Building Project "ReferencedProj.csproj" (default targets) -- FAILED.
This approach is very similar to what's suggested in this answer:
https://stackoverflow.com/a/7077178/176877
The crucial difference may be that I'm in Visual Studio 2012, rather than VS2008 or 2010.
Old question, but in case this helps anyone, this simple, stripped back approach worked fine for me:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
...
<BuildDependsOn>
$(BuildDependsOn);
PublishOtherProject;
</BuildDependsOn>
</PropertyGroup>
<Target Name="PublishOtherProject">
<MSBuild Projects="pathtomyproject.csproj" Properties="DeployOnBuild=true;PublishProfile=nameOfPublishProfile" />
</Target>
The key line being:
<MSBuild Projects="pathtomyproject.csproj" Properties="DeployOnBuild=true;PublishProfile=nameOfPublishProfile" />
I have a library with a pretty verbose configuration section. I've created an XSD and would like to distribute that with my package so that when a user installs the package, Visual Studio knows about the XSD without the user needing to do anything extra. How do I do this?
You can include any files you want in a nuget package by placing them in the content directory. These will then be installed into the root of your target project when the package is installed. If you're using a nuspec file to build your package you would add the following element under the element.
<files>
<file src="Configuration\MyXsd.xsd" target="content\TargetFolderName" />
</files>
This will create the following file in the target project
\TargetFolderName\MyXsd.xsd
Once the xsd is in the target project visual studio should pick it up automatically for validating your config section.
This has recently become more complicated with SDK style projects and the different ways of referencing nuget packages.
Note the end of this section.
Basically, if a nuget project is referenced by package.config file, the files from the content folder of the nuget package will be copied to the referencing project. If the nuget package is referenced by PackageReference in the project file, the files from the contentFiles folder within the package will be used. It is recommended to include both.
Now if you are using a .nuspec file to configure your nuget package, you can use SynXsiS answer to include the file to both directories:
<files>
<file src="Configuration\MyXsd.xsd" target="content\TargetFolderName" />
<file src="Configuration\MyXsd.xsd" target="contentFiles\any\any\TargetFolderName" />
</files>
However, if you want to configure it in the .csproj file of SDK projects, you have to add the file you want to include in the nuget package into the project file with the following properties:
<ItemGroup>
<None Include="MyXsd.xsd">
<Pack>true</Pack>
<PackagePath>contentFiles\any\any\TargetFolderName;content\TargetFolderName</PackagePath>
</None>
</ItemGroup>
The any\any\ part of the path for the contentFiles specifies for which language (cs, vb, ...) and target framework the file is meant.
Note, that the item not necessarily has to be of type "None" it could also be "Content" and others as described here.
You can find all information for this structure here, general information of the folder structure can be found here and help for the SDK style projects here.
I am trying to do a Jenkins-based automated build/deployment of a web application (.NET 4.0). The web application project has several project references, which in turn have binary references third party DLLs.
The problem:
The second-level references (references of project references) are not pulled into the bin folder in the obj\<CONFIGURATION>\Package\PackageTmp\bin folder, used for building deployment packages.
When I build in the visual studio, the second level references are pulled into the regular build output directory.
When building with MSBuild, second level dependencies are not pulled into the regular output directory, nor into the PackageTmp\bin directory.
This is confirmed by MS as a Won't-Fix issue here.
Related questions here, here and here either do not match my problem, or offer solutions that don't work. I've reviewed all answers, not just the accepted ones.
My build command looks like this (using MSBuild 4.0):
MSBuild MySolution.sln /p:Configuration=Integration /p:platform="Any
CPU" /t:Clean,Build /p:DeployOnBuild=true /p:DeployTarget=Package
/p:AutoParameterizationWebConfigConnectionStrings=false
I've tried to manually edit Reference elements in project files, adding <Private>True</Private>, with no success.
I am trying to work around this known issue, so that my second-level dependencies are automatically and correctly pulled into the web publishing temp directory.
My current attempt combines the general approach here (customizing the web publishing pipeline by adding a MyProject.wpp.targets file next to the web project file), combined with some MSBuild code for finding DLLs here. So far this has either produced no results or broken the project file. I am new to custom MSBuild code and find it pretty arcane.
My Question: I am looking for a more complete example that works in my specific case. I think the goal is to intervene in the web publishing pipeline that gathers files for copying to the package temp directory, and adding the second-level dependencies to it.
My custom MyWebProj.wpp.targets looks like this:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<BRPathFiles Include="$(SolutionDir)..\Common\**\*.dll;$(SolutionDir)**\*.dll" />
<ConfigPathFiles Include="$(SolutionDir)..\Common\**\*.config;$(SolutionDir)**\*.config" />
</ItemGroup>
<Target Name="CopySecondLevelDependencies" BeforeTargets="CopyAllFilesToSingleFolderForPackage">
<RemoveDuplicates Inputs="#(BRPathFiles->'%(RootDir)%(Directory)')">
<Output TaskParameter="Filtered" ItemName="BRPaths" />
</RemoveDuplicates>
<RemoveDuplicates Inputs="#(ConfigPathFiles->'%(RootDir)%(Directory)')">
<Output TaskParameter="Filtered" ItemName="ConfigPaths" />
</RemoveDuplicates>
<CreateItem Include="%(BRPaths.Identity);%(ConfigPaths.Identity);">
<Output ItemName="FileList" TaskParameter="Include"/>
</CreateItem>
<CreateItem Value="#(BRSearchPath);$(ConfigSearchPath)">
<Output TaskParameter="Value" PropertyName="SecondLevelFiles" />
</CreateItem>
</Target>
<ItemGroup>
<FilesForPackagingFromProject
Include="%(SecondLevelFiles->'$(OutDir)%(FileName)%(Extension)')">
<DestinationRelativePath>$(_PackageTempDir)\bin\%(FileName)%(Extension) </DestinationRelativePath>
<FromTarget>CopySecondLevelDependencies</FromTarget>
<Category>Run</Category>
</FilesForPackagingFromProject>
</ItemGroup>
</Project>
Assuming you have collected all libraries needed at runtime in a folder outside your solution/project, have you tried just using post-build events to copy all these libraries to your main project target directory (bin) and then include that directory in your deployment package using Sayeds method: http://sedodream.com/2010/05/01/WebDeploymentToolMSDeployBuildPackageIncludingExtraFilesOrExcludingSpecificFiles.aspx (also available in this post: How do you include additional files using VS2010 web deployment packages?)?
I have (among others) the following line in my main project's post-build events:
xcopy "$(ProjectDir)..\..\Libraries\*.dll" "$(TargetDir)" /Y /S
In addition to this, I have added the following lines to my .csproj file:
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>
PostBuildLibraries;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>
</PropertyGroup>
<Target Name="PostBuildLibraries">
<ItemGroup>
<_PostBuildLibraries Include="$(TargetDir)**\*" />
<FilesForPackagingFromProject Include="%(_PostBuildLibraries.Identity)">
<DestinationRelativePath>$(OutDir)%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
Be sure to add these lines after the import of the "Microsoft.WebApplication.targets". Check out the links above for more details.
This makes all the desired libraries available after each build (copied to the project's target directory) and each time I create a deployment package (copied to the obj\<CONFIGURATION>\Package\PackageTmp\bin).
Also, since I'm building my main project, not my solution, I'm using the $(ProjectDir) macro instead of the $(SolutionDir).