I installed the ABCpdf.ABCGecko package via nuget, and it gave me this dialog:
Finished! Please deploy the XULRunner folder to your output directory manually.
I don't really know wtf this means... I have an idea, but don't know precisely where or how to modify my build configuration to allow this to occur. Has anyone done this, and if so, how?
My original attempted answer worked fine for my development setup, but didn't work on our staged deployment setup, as for some reason it didn't include the XULRunner files inside the web package created using MSDeploy. I've found what seems to be a simpler setup, below:
<ItemGroup>
<Content Include="XULRunner\**\*.*">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
I'm not 100% sure if this works universally, but it seems to work better in every development and deployment scheme I've encountered thus far.
I found how to accomplish this via this SO answer. The relevant changes to the project's .csproj file are below:
<Target Name="AfterBuild">
<CallTarget Targets="CopyXULRunnerToDeployFolder" />
</Target>
<Target Name="CopyXULRunnerToDeployFolder">
<ItemGroup>
<MyFiles Include="XULRunner\**\*.*" />
</ItemGroup>
<Microsoft.Build.Tasks.Copy SourceFiles="#(MyFiles)" DestinationFiles="#(MyFiles->'$(OutputPath)\XULRunner\%(RecursiveDir)%(Filename)%(Extension)')"/>
</Target>
Related
So basically I am building nuget packages in TeamCity via a .proj file that runs a "pack" target:
<MSBuild
Projects="$(MSBuildProjectDirectory)\PROJNAME.csproj"
Targets="Rebuild;pack"
Properties="Configuration=$(Configuration);Version=$(BUILD_NUMBER)" />
With an artifact output of:
PROJNAME\bin\Release\PROJNAME.%build.number%.nupkg
This works nicely for basic consuming of the nuget package, however I am having trouble getting the documentation xml files to work.
I have looked inside the output nupkg and I see that the documentation xml is actually bundled and included in the package, however the problem is that when I finally restore nuget packages in my consuming project, the dll gets copied across as expected, however the documentation does not.
I wondered if this is because of the TC generated .nuspec file, and if I may need to abandon teamcities nuspec and create my own, however I was hoping to avoid this, given it works nicely the way it is, and handles versioning etc.
Is there a simple way to include documentation xml when the package is restored?
In the end i found it came down to 3 things, being:
Ensure projects configuration is set to generate documentation.
Either by adding code manually such as:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'"><DocumentationFile>bin\$(Configuration)\netstandard2.0\Project.documentation.xml</DocumentationFile>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'"> <DocumentationFile>bin\$(Configuration)\netstandard2.0\Project.documentation.xml</DocumentationFile>
</PropertyGroup>
Or alternatively via the Visual Studio Project properties menu, if you are doing it through VS also make sure you do it for all configurations (as depicted as A in the picture below):
Add EnableDocumentationFile to your .csproj file, eg:
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<RootNamespace>project</RootNamespace>
<Configurations>Debug;Release</Configurations>
<EnableDocumentationFile>true</EnableDocumentationFile>
</PropertyGroup>
and most importantly let your project know (again in your .csproj) that it should be copying over the documentation file, and use PackageFlatten if you want it to appear at the same level as your package dll:
<ItemGroup>
<None Remove="bin\$(Configuration)\netstandard2.0\Project.documentation.xml" />
</ItemGroup>
<ItemGroup>
<Content Include="bin\$(Configuration)\netstandard2.0\Project.documentation.xml">
<Pack>true</Pack>
<PackageCopyToOutput>true</PackageCopyToOutput>
<PackageFlatten>true</PackageFlatten>
</Content>
</ItemGroup>
I intended to use Fody.PropertyChanged in one of my projects, and it was properly added via NuGet:
Install-Package PropertyChanged.Fody
I realized, it was in the wrong project, so I used the uninstall command:
Uninstall-Package PropertyChanged.Fody
After that I added it to the proper project.
Now, when I try to build my solution, I get the following error in the initial project that shouldn't have Fody installed:
Fody: You don't seem to have configured any weavers. Try adding a Fody
nuget package to your project. Have a look here
http://nuget.org/packages?q=fody for the list of available packages.
There is no reference to Fody in the project, I deleted the Fody reference from the packages.config file and there is no XML file.
What else should I do?
You need to also
Uninstall-Package Fody
Remove The "FodyWeavers.xml" and Open the Project file with NotePad or notePad++ and remove the following lines
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<Import Project="..\packages\Fody.1.29.2\build\portable-net+sl+win+wpa+wp\Fody.targets" Condition="Exists('..\packages\Fody.1.29.2\build\portable-net+sl+win+wpa+wp\Fody.targets')" />
I guess you've recently updated the Fody library? When it asked to replace the existing "FodyWeavers.xml" you might have permitted it to do so. If you have a backup of the project, get the "FodyWeavers.xml" from that and replace it with the new one. Clean and Rebuild the solution.
This doesn't specifically address the project you don't want Fody in, but sometimes VS gives vague/odd errors.
I just went through a similar issue after installing PropertyChanged.Fody for the first time, and couldn't build as soon as I included and referenced it... I wonder if any of these details from my experience might help (making sure these points exist in the project you want the lib in).
Make sure you have the following references in your packages.config from when you ran Install-Package PropertyChanged.Fody:
<package id="Fody" version="1.24.0" targetFramework="net45" developmentDependency="true" />
<package id="PropertyChanged.Fody" version="1.49.0" targetFramework="net45" developmentDependency="true" />
Make sure there is FodyWeavers.xml in the top level of the project you want to use it in.
FodyWeavers.xml should look like this (I had to add <PropertyChanged /> to mine)
<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
<PropertyChanged />
</Weavers>
I'm having trouble trying to find the right way to use MSBuild to build a web project and output the project with only deployable files (i.e. no .cs, .csproj, .Debug.config etc.), but published to a local folder that I can then FTP, RoboCopy, (or whatever) to a secondary location.
The published output must have the Web.config file pre-transformed as per the specified configuration and the transformation config files (e.g. Web.Debug.config) not included in the output. I don't need any fancy publishing to IIS, database deployment or anything like that, I just want clean file system output that I can then test. Note that this cannot be done using visual tools as I want to run it as part of an automated build process.
I can generate a web deployment package, but I can't get WebDeploy to work because it doesn't seem to handle quoted command line options anymore (seems to be some kind of bug) and the directory structure has spaces, so I was hoping to accomplish the whole task using MSBuild, seeing as MSBuild seems to have native capacity to transform the config file (TransformXml), which is the only real bit of proper deployment functionality I'd be using.
Got it figured out eventually. The following build script does the trick:
<?xml version="1.0"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll"/>
<PropertyGroup>
<OutputDir>obj\website-output</OutputDir>
</PropertyGroup>
<Target Name="PrepareDeploy">
<ItemGroup>
<DeployableFiles Include="App_Code/**/*.*;App_Data/**/*.*;Areas/**/Views/**/*.*;bin/**/*.*;Views/**/*.*;*.aspx;*.asax;*.html;*.htm;sitemap.xml;*.ico;*.png" Exclude="App_Data/**/*.log" />
</ItemGroup>
<RemoveDir ContinueOnError="true" Directories="$(OutputDir)" />
<MSBuild Projects="Website.csproj" />
<MakeDir ContinueOnError="true" Directories="$(OutputDir)" />
<Copy SourceFiles="#(DeployableFiles)" DestinationFiles="#(DeployableFiles->'$(OutputDir)\%(RelativeDir)%(Filename)%(Extension)')" />
<TransformXml Source="Web.config" Transform="Web.$(Configuration).config" Destination="$(OutputDir)\web.config" />
</Target>
</Project>
I want to deploy my ASP.NET MVC site and have the following script.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\MyProjName\MyProjName.csproj"/>
<PropertyGroup>
<NewInstallDir>C:\DeployFolder\</NewInstallDir>
<BinDir>$(NewInstallDir)bin\</BinDir>
</PropertyGroup>
<Target Name="Build">
<MSBuild Projects="..\MySlnName.sln"
Properties="Configuration=Release;Platform=Any CPU;OutputPath=$(BinDir)" />
<Copy SourceFiles="#(Content->'..\MyProjName\%(RelativeDir)%(FileName)%(Extension)')"
DestinationFiles="#(Content->'$(NewInstallDir)%(RelativeDir)%(FileName)%(Extension)')" />
<Copy SourceFiles="#(None->'..\MyProjName\%(RelativeDir)%(FileName)%(Extension)')"
DestinationFiles="#(None->'$(NewInstallDir)%(RelativeDir)%(FileName)%(Extension)')" />
<MakeDir Directories="#(Folder->'$(NewInstallDir)%(RelativeDir)')" />
</Target>
</Project>
Main idea.
I copied binary to C:\DeployFolder (take structure of folder from sources). I build my dll to C:\DeployFolder\Bin (I don't have this folder in sources folder so I need separately copy this).
I run my script - all works instead of copy DLLs to OutputPath. Same scripts works for other asp.net mvc project. I have no idea what is wrong in this case.
I complete this issue with workaround but I would like to know what is wrong with this script.
The first thing I'd try is to replace your use of the deprecated $(OutputPath) with $(OutDir). From when I've seen this error, 9 times out of 10 it is due to a mismatch between the Platform/Configuration requested and how a particular project is actually defined. Take care to keep track of the discrepency between "Any CPU" (with a space) preferred by solution files and "AnyCPU" actually used inside project files for $(Platform). Some project wizards only set up an "x86" Platform or otherwise omit "AnyCPU" which can cause the OutputPath to be empty.
Beyond that, the approach of importing a project file and then building a solution (presumbably that includes the very same project" is a bit off center. Consider making the deployment changes you desire within the project file itself, through an import. You can either wire into the existing build targets at the right place, or perhaps add an additional target.
Prior to NuGet, it was common accepted 'best practice' to check-in all external DLLs used on a project. Typically in a Libs or 3rdParty directory.
When working with NuGet, am I supposed to check-in the packages directory, or is there a way for MSBuild to auto download the needed packages from the nuget feed?
No
Since this question was asked there is now an easy workflow to use NuGet without commiting packages to source control
From your package manager console you need to install the 'NuGetPowerTools':
Install-Package NuGetPowerTools
Then to enable your projects to support pack restore you need to run another command:
Enable-PackageRestore
Now you are ready to commit your code base without the packages folder. The previous command changed your project files so that if packages are missing they get automatically downloaded and added.
Source
Using NuGet without committing packages to source control
Yes. Consider the "packages" directory to be equivalent to your "libs" directory that you mentioned in your question. This is the approach I personally take with my OSS projects.
We are investigating features that would allow MSBuild to auto download the needed packages, but that hasn't been implemented (as of NuGet 1.1).
I think some people may have already implemented such features on their own, but our plan is to look at having that feature built in to NuGet 1.2 or 1.3 hopefully.
Despite all the answers here, it is still a plain ole' horrible solution to not have all your dependencies under "some kind" of version control.
For GIT, this would mean GIT-LFS.
The recent episode with NPM shows why: If the internet repository of which you depend breaks, are unavailable etc., well then you're screwed aint you?
You are no longer able to build your stuff - and therefore not able to deliver.
Since asking the question, I've put in the following approach so that I do not have to check in the toplovel Packages directory.
In a toplevel build.msbuild file:
<Target Name="NuGet">
<ItemGroup>
<NuGetPackage Include="*\packages.config" />
</ItemGroup>
<Exec Command='libs\NuGet.exe install "%(NuGetPackage.FullPath)" -o Packages' />
<!-- optional for project that has JavaScript content -->
<CreateItem Include="Packages\*\Content\Scripts\*">
<Output TaskParameter="Include" ItemName="NuGetJSFiles"/>
</CreateItem>
<Copy SourceFiles="#(NuGetJSFiles)" DestinationFolder="MainProj\Scripts\" OverwriteReadOnlyFiles="true" SkipUnchngedFiles="true" />
<Delete Files="MainProj\Scripts\.gitignore" />
<WriteLinesToFile File="MainProj\Scripts\.gitignore" Lines="%(NuGetJSFiles.Filename)%(NuGetJSFiles.Extension)" /
<Delete Files="#(PostNuGetFiles)" />
</Target>
In each project.csproj file
<Target Name="BeforeBuild">
<Error Condition="!Exists('..\Packages\')" Text="You must run > msbuild build.msbuild to download required NuGet
Packages" />
<!-- optional for project that has JavaScript content -->
<ReadLinesFromFile File="Scripts\.gitignore">
<Output TaskParameter="Lines" ItemName="ReqJSFiles" />
</ReadLinesFromFile>
<Message Text="#(ReqJSFiles)" />
<Error Condition="!Exists('Scripts\%(ReqJSFiles.Identity)')" Text="You must run > msbuild build.msbuild to download required NuGet JS Package - Scripts\%(ReqJSFiles.Identity)" />
</Target>
I realize the reality was different when this question has been originally posted and answered, but fortunately the answer changed a bit. It is now possible to use NuGet to download dependencies via MSBuild using a Pre-Build event. You don't need to put the packages folder in your code repository, all dependencies will be downloaded and/or updated on build. It may a workaround, but it looks decent enough. See the following blog post for details: http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
AS of 09/20/13, there is something called "Nuget Restore". You actually don't have to check in package folder if you wish to do so. (Especially if you are using DVCS)
Check out this: Using NuGet Without commiting packages to source control
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
This post has become very outdated. The answer is still NO, but the solution has changed.
As of NuGet 2.7+ you can enable automatic package restore without including the NuGet.exe file in your source (this is undesirable to say the least) and if you use any modern DVCS you can ignore the packages folder. If you need any special customizations you can create a nuget.config file in the solution root.
http://docs.nuget.org/docs/reference/package-restore
Also, with the new csproj format you can avoid the extra nuget.config files as well since that is integrated now. Please check out this post which explains that better:
Should .nuget folder be added to version control?