I am using visual studio 2013 & Fluent Validation 5.6.2
I see that after build in the bin folder it copies all the culture specific FluentValidation.resources.dll which seems to be mentioned it in .nuspec file
> <file src="lib\NET35\de\FluentValidation.resources.dll"
> target="lib\NET35\de\FluentValidation.resources.dll" />
> <file src="lib\NET35\es\FluentValidation.resources.dll" target="lib\NET35\es\FluentValidation.resources.dll" />
> <file src="lib\NET35\fr\FluentValidation.resources.dll" target="lib\NET35\fr\FluentValidation.resources.dll" />
> <file src="lib\NET35\it\FluentValidation.resources.dll" target="lib\NET35\it\FluentValidation.resources.dll" />
> <file src="lib\NET35\nl\FluentValidation.resources.dll" target="lib\NET35\nl\FluentValidation.resources.dll" />
> <file src="lib\NET35\pt\FluentValidation.resources.dll" target="lib\NET35\pt\FluentValidation.resources.dll" />
> <file src="lib\NET35\sv\FluentValidation.resources.dll" target="lib\NET35\sv\FluentValidation.resources.dll" />
But I do not need these in bin folder, because project does not support any culture specific messages.
So how can I tell vs-build to ignore these culture specific dlls?
My solution was to add this target at the end of the .csproj file before the closing project tag.
<Target Name="AfterPackage" AfterTargets="CopyAllFilesToSingleFolderForPackage" />
<ItemGroup>
<FluentValidationExcludedCultures Include="cs;da;de;es;fa;fi;fr;it;ko;mk;nl;pl;pt;ru;sv;tr;zh-CN">
<InProject>false</InProject>
</FluentValidationExcludedCultures>
</ItemGroup>
<Target Name="RemoveTranslationsAfterBuild" AfterTargets="AfterBuild">
<RemoveDir Directories="#(FluentValidationExcludedCultures->'$(OutputPath)%(Filename)')" />
</Target>
<Target Name="RemoveTranslationsAfterPackage" AfterTargets="AfterPackage">
<RemoveDir Directories="#(FluentValidationExcludedCultures->'$(_PackageTempDir)\$(OutputPath)%(Filename)')" />
</Target>
It's not pretty, but it gets the job done. If you need some culture specific resource, just remove the corresponding line from the list. If a future update adds a new culture that you don't want, add it to the list.
The best option would be ask the developer to separate the resources in multiple nugets, this way you could just add the ones needed. I'll stick with this solution, for now, until someone come up with a better one.
Now you can find my solution at the official project wiki: https://github.com/JeremySkinner/FluentValidation/wiki/f.-Localization (at the bottom of the page)
i had same problem with external library, i'm add post-build script in Visual Studio project properties, which delete all folders (for me it`s okay, otherwise set list of dirs) at output directory:
FOR /D %%d IN ($(TargetDir)*) DO RMDIR /S /Q %%d
Related
Currently I'm working on an UWP NuGet package for making it easier to create great popups and dialogs.
Currently the project is newborn and doesn't have so much controls but I tried to create a NuGet package for it to be a test for making sure it is all good.
Unless I'm using app with the class library referenced to the sample project all things working well but after downloading the library from NuGet I'm getting XamlParseException error.
I searched a bit and find it out that I should add some xaml, xbf or somethings in the output so I tried to add the following lines to my nuspec.
<files>
<!-- XAML controls -->
<file src="Controls\MessageBoxControls\MessageBoxControl.xaml" target="lib\netcore50\Controls\MessageBoxControls"/>
<file src="bin\Debug\UWPPopupToolkit\Controls\MessageBoxControls\MessageBoxControl.xbf" target="lib\netcore50\Controls\MessageBoxControls"/>
<file src="Controls\PopupControlControls\PopupControl.xaml" target="lib\netcore50\Controls\PopupControlControls"/>
<file src="bin\Debug\UWPPopupToolkit\Controls\PopupControlControls\PopupControl.xbf" target="lib\netcore50\Controls\PopupControlControls"/>
<file src="Controls\SlideupPopupControls\SlideupPopup.xaml" target="lib\netcore50\Controls\SlideupPopupControls"/>
<file src="bin\Debug\UWPPopupToolkit\Controls\SlideupPopupControls\SlideupPopup.xbf" target="lib\netcore50\Controls\SlideupPopupControls"/>
</files>
But still I'm getting same error any idea how to solve it?
I should mention that the project is currently available on Github on the following link
https://github.com/NGame1/UWPPopupToolkit
and the NuGet package also is available here
https://www.nuget.org/packages/UWPPopupToolkit
Simply placing the content files in the lib folder of the nuget package will not automatically copy it into the build output folder, only the dll, pdb and xml files will be added into the output projects automatically.
Since your additional files are not the same type, so you cannot get what you want by your method. So I suggest you could try this:
Solution
1) create a folder called build on your root directory of your project and then add a file called <package_id>.props file.
Note: the file must be named the same as your nuget package so that it will work. For an example, if your nuget project named as UWPPopupToolkit.0.0.1-rc.nupkg, the file must be named as UWPPopupToolkit.props.
2) add these content into the UWPPopupToolkit.props file:
<Project>
<Target Name="OutputExtraFiles" BeforeTargets="Build">
<ItemGroup>
<File Include="$(MSBuildThisFileDirectory)..\File\**\*.*"></File>
</ItemGroup>
<Copy SourceFiles="#(File)" DestinationFiles="$(TargetDir)\%(RecursiveDir)%(Filename)%(Extension)"></Copy>
</Target>
</Project>
3) modify your UWPPopupToolkitSDK.nuspec file like this:
<files>
<!-- XAML controls -->
<file src="Controls\MessageBoxControls\MessageBoxControl.xaml" target="File\Controls\MessageBoxControls"/>
<file src="bin\Debug\UWPPopupToolkit\Controls\MessageBoxControls\MessageBoxControl.xbf" target="File\Controls\MessageBoxControls"/>
<file src="Controls\PopupControlControls\PopupControl.xaml" target="File\Controls\PopupControlControls"/>
<file src="bin\Debug\UWPPopupToolkit\Controls\PopupControlControls\PopupControl.xbf" target="File\Controls\PopupControlControls"/>
<file src="Controls\SlideupPopupControls\SlideupPopup.xaml" target="File\Controls\SlideupPopupControls"/>
<file src="bin\Debug\UWPPopupToolkit\Controls\SlideupPopupControls\SlideupPopup.xbf" target="File\Controls\SlideupPopupControls"/>
<file src="build\UWPPopupToolkit.props" target="build" />
</files>
4) then repack your nuget project, before you install the new version of the nuget package, please clean the nuget caches first and also delete the bin, obj or any output folders of your main project.
=================================
Update 1
In my side, clean all nuget caches or delete all cache files under C:\Users\xxx(current user)\.nuget\packages and then install the new version of the nuget package, the target files are output to bin\x86\Debug\Controls,
If I install the new version 0.0.1.5-rc,everything works well. See this:
Not sure if your problem is that the files are missing or you want to put them into bin\x86\Debug\netcore50\Controls.
If your issue is the second, you should modify your UWPPopupToolkit.props,
use this:
<Copy SourceFiles="#(File)" DestinationFiles="$(TargetDir)netcore50\%(RecursiveDir)%(Filename)%(Extension)"></Copy>
After that, delete bin and obj folder and then rebuild your main project again.
Thanks to #Perry Qian-MSFT
Finally, I got able to fix the issue.
adding files like this
<files>
<!-- Dll -->
<file src="bin\Release\UWPPopupToolkit.dll" target="lib\netcore50" />
<!-- Resources -->
<file src="bin\Release\UWPPopupToolkit.pdb" target="lib\netcore50" />
<file src="bin\Release\UWPPopupToolkit.pri" target="lib\netcore50" />
<!-- IntelliSense -->
<file src="bin\Release\UWPPopupToolkit.XML" target="lib\netcore50" />
<!-- XAML control -->
<file src="bin\Release\UWPPopupToolkit\**\*.*" target="lib\netcore50\UWPPopupToolkit" />
<!-- Icon -->
<!--<file src="..\icon.png" target="images\" />-->
</files>
solved the problem.
You can find the result files here: UWPPopupToolkitSDK.nuspec | UWPPopupToolkit.props | UWP Popup Toolkit Github
I have an .exe app that I need to distribute with my C# app when it builds. I am trying to use Nuget to package it so that it will be included in the build root directory when building but am having trouble getting the behaviour I want.
Here is what I've got in my .nuspec file:
<?xml version="1.0"?>
<package>
<metadata>
<id>my.id</id>
<version>1.0.0</version>
<authors>me</authors>
<owners>me</owners>
<licenseUrl>myurl</licenseUrl>
<projectUrl>myurl</projectUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>A copy of an .exe so we can easily distribute it
with our applications without needing to include it in our VCS repo</description>
<releaseNotes>Initial test version</releaseNotes>
<copyright>Copyright 2018</copyright>
<dependencies>
</dependencies>
<packageTypes>
</packageTypes>
<contentFiles>
<files include="any\any\myexe.exe" buildAction="None" copyToOutput="true" />
</contentFiles>
</metadata>
<files>
<file src="content\myexe.exe" target="content" />
</files>
</package>
This puts the myexe.exe file to my VS project when I install the Nuget Package but it does not copy the file when I build. What I'd like is for the file to by installed with my other app files when building and to keep it out of my VS project.
I've been reading docs here but am not sure how to make the nuspec file.
More Details:
Nuget 4.5.1
Visual Studio 2015
Note: the <files> and <contentFiles> might seem to be duplicating functionality. I'd like to employ both as I understand this will future-proof it for VS2017
Nuget: Including an exe as a Run-time dependency
First, I know you want to use some technologies for the future, but we have to know that these future-oriented technologies often have certain constraints and conditions.
For example, <contentFiles> is used for NuGet 4.0+ with PackageReference, neither of them is supported by Visual Studio 2015. See Using the contentFiles element for content files for some details.
If you are interested in the <contentFiles>, you can read the blog NuGet is now fully integrated into MSBuild.
Go back to our question now, according to above info, we should not use <contentFiles> when we use Visual Studio 2015. To resole this issue, we need to add a .targets file in the nuget package when you build the project:
The content of .targets file:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<None Include="$(ProjectDir)myexe.exe">
<Link>myexe.exe</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CustomToolNamespace></CustomToolNamespace>
</None>
</ItemGroup>
</Project>
The .nuspec file like following:
<files>
<file src="build\YouNuGetPackageName.targets" target="build\YouNuGetPackageName.targets" />
<file src="content\myexe.exe" target="content\myexe.exe" />
</files>
Note: The name of the .targets file should be same as your nuget package name.
With this way, when you build your project, MSBuild/VS would copy the file myexe.exe to the output folder.
Besides, if you want to copy the file myexe.exe to other destination, you can replace the content of .targets file with a copy task, like:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="CopyMyexe" BeforeTargets="Build">
<Message Text="Copy CopyMyexe to the folder."></Message>
<Copy
SourceFiles="$(ProjectDir)myexe.exe"
DestinationFolder="xxx\xxx\xx\myexe.exe"
/>
</Target>
</Project>
See Creating native packages and similar issue for some helps.
Hope this helps.
How can I merge and make use of Web.debug.config in visual studio 2010 built-in debugger?
This is a known bug. That feature can be used right now only as part of the deploy process.
https://connect.microsoft.com/VisualStudio/feedback/details/523221/have-web-debug-config-apply-during-development
Please upvote it, if you encounter this too, so this will be fixed ASAP.
This is actually quite simple to do and, believe it or not, it seems this is the way VS is designed to work.
Add the following lines verbatim right before the closing "Project" tag of the .csproj file of the project that contains web.config.
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="Transform">
<MakeDir Directories="obj\$(Configuration)" Condition="!Exists('obj\$(Configuration)')" />
<TransformXml Source="Web.Config" Transform="Web.$(Configuration).config" Destination="obj\$(Configuration)\Web.config" StackTrace="true" />
</Target>
Put the following lines verbatim to the post-build event in the project properties of the project that contains the web.config file. Do this for each build configuration you want the transformations to run for.
"$(MSBUILDBINPATH)\msbuild" "$(ProjectPath)" /t:Transform /p:Configuration=$(ConfigurationName);Platform=AnyCPU
xcopy "$(ProjectDir)obj\$(ConfigurationName)\Web.Config" "$(ProjectDir)". /F /R /Y
I had solved this in a simpler way, by adding this at the end of the .csproj file, right before the tag. This is similar to keitn's answer, with the difference that it doesn't use a post build event.
<Target Name="BeforeBuild">
<TransformXml Source="Web.config" Transform="Web.$(Configuration).config" Destination="Web.config" />
</Target>
I didn't want to update the web.config in my project just the one that ends up in the bin folder so here is how I did it.
Add the following to the end of .csproj (just before the final closing project tag)
<Target Name="Transform">
<MakeDir Directories="bin" Condition="!Exists('bin')" />
<TransformXml Source="Web.Config" Transform="Web.$(Configuration).config" Destination="bin\$(TargetFileName).config" StackTrace="true" />
</Target>
Then add the following post build step
"$(MSBUILDBINPATH)\msbuild" "$(ProjectPath)" /t:Transform /p:Configuration=$(ConfigurationName);Platform=AnyCPU
This means that when you build a transform takes place from the debug/release config to WebsiteName.Config file in the output bin directory thus not interfering with the main web.config in the project.
After reading many similar posts and having problems with files not being able to be overwritten or web.config not being accessible because it is read only this is what I got working for me:
<Target Name="BeforeBuild" Condition="$(Configuration) == 'MyAltDebugConfiguration'">
<ItemGroup>
<OriginalWebConfig Include="$(ProjectDir)Web.config"/>
<TempWebConfig Include="$(ProjectDir)TempWeb.config"/>
</ItemGroup>
<Exec Command=""$(DevEnvDir)tf.exe" checkout "$(ProjectDir)Web.config"" />
<Copy SourceFiles="#(OriginalWebConfig)" DestinationFiles="#(TempWebConfig)" />
<TransformXml Source="$(ProjectDir)TempWeb.config"
Transform="Web.$(Configuration).config"
Destination="Web.config" />
</Target>
Notes:
This runs as the BeforeBuild target.
I only want it to run under a certain configuration (an alternative debug environment) and so that is why I have the Condition. When deploying via web deploy the publishing target kicks in and I don't need this target to run.
I don't want to have to remember to check out web.config (only to undo it when I am done) so I check web.config out before beginning the transform. If you aren't using TFS you can remove this line.
Because VS (2010) \ msbuild doesn't want to let go of the Source web.config I use a temp file (thanks to this article for the info: http://www.diaryofaninja.com/blog/2011/09/14/using-custom-webconfig-transformations-in-msbuild)
I tried adding a command to delete the TempWeb.config but VS \ msbuild doesn't want to let go of it. I can live with it as it doesn't get added to TFS.
I know this is old, but I'm facing the same problem. We have Test, Staging, Live configs that replace endpoints, connection strings etc. from the default Web.config
However I would do the following:
Right click on the desired transform config (e.g. Web.Live.config)
Click on "Preview Transform"
Copy everything from right (it's how the Web.config looks with the transformation)
CTRL+A + CTRL+C
Open Web.config file (default one)
Select everything (CTRL+A) and paste it in (CTRL+V)
Run
It's not that many steps and is done pretty quickly when you get a hang of it. Hope this helps. :)
#ologesa:
Your solution needs write access to the original Web.config (you must check-out in TFS).
The better solution is to directly generate the Web.config in the bin folder like keitn does this. When we combine keitn's and your solution we get this one:
<Target Name="BeforeBuild">
<Message Text="Transforming Web.config from Web.$(Configuration).config" Importance="high" />
<MakeDir Directories="bin" Condition="!Exists('bin')" />
<TransformXml Source="Web.Config" Transform="Web.$(Configuration).config" Destination="bin\$(TargetFileName).config" StackTrace="true" />
</Target>
I have a solution where I have different app.configs, given a different configuration. Drawback is that an installer (created using Wix) is created for a specific configuration. I would like to do this on install time, such that I can start the installer with a command line parameter to do the xml transformation, to be able to use the same installer in different environemnts (development, test, accpetance).
So, currently I have the transform in the csproj file:
<Target Name="AfterBuild">
<TransformXml Source="App.config" Transform="App.$(Configuration).config" Destination="$(OutputPath)\$(AssemblyName).exe.config" />
</Target>
What I want to do is:
msiexec /i installer.msi PROD
such that the transformation in app.PROD.config is executed. Is there a way in Wix to achieve that using the transformations?
Instead of transforming the original file at install time, it is easier to include all transformed app.config files into the MSI package and then choose the appropriate one during at install by passing the property value.
The snippet of the wxs file might look like this:
<Component Id="AppConfigDev" Guid="...">
<Condition>MODE = "DEV"</Condition>
<File Name="app.config" Id="app.dev.config" KeyPath="yes" Source="$(var.Source)\app.DEV.config" />
</Component>
<Component Id="AppConfigTest" Guid="...">
<Condition>MODE = "TEST"</Condition>
<File Name="app.config" Id="app.test.config" KeyPath="yes" Source="$(var.Source)\app.TEST.config" />
</Component>
<Component Id="AppConfigProd" Guid="...">
<Condition>MODE = "PROD"</Condition>
<File Name="app.config" Id="app.prod.config" KeyPath="yes" Source="$(var.Source)\app.PROD.config" />
</Component>
As a result, when you pass in the value of MODE through the command line, only one of the components above will be installed, and it will end up in the target directory as app.config.
Note that Windows Installer will throw a warning saying the conditions must be mutually exclusive in order for this technique to work. As long as MODE property can only have one value at a time, these conditions are mutually exclusive by definition, but the warning is there.
I'm thinking that the final result is going to be "it can't be that easily done", but just seems like it should be. I have a personal project I am working on. I'd hate to have to manually (or even in script) change versions, company, copyright, and all that on ALL the assembly.cs files and would like all that to be either in a script or in a file I can change (so the script stays the same mostly) when I want to update the version. But it seems like MSBuild is mostly a "build as is specified in Visual Studio". I'd just hate to have all that history of these files where I change just the version and possibly even make a mistake as this project will continue to get bigger and bigger. I'd like to just be able to add a new project to Visual studio and have whatever command line in my powershell script just say "compile this, but give it this company name and this file version instead of whatever is listed in the code file".
Google has NOT proven fruitful in this. I've even found it difficult to build my files to a specific folder. I've had to so far make sure all my projects are 2 folders deep and was able to say to build them at ....\, but I would like to be able to change that randomly if I like and have them built elsewhere if I so desire.
Is MSBuild perhaps not the way to go? Is there someway else to build visual studio that would be better from command line? Eventually I also want to auto build the install with wix and be able to match its version with the binary versions.
thank you
Since csproj is xml, you can use XmlUpdate "helpers" to modify the values inside the csproj file before you do your build.
For other files, you can use some other Tasks to do the job.
Here is one helpful target:
http://msbuildtasks.tigris.org/ and/or https://github.com/loresoft/msbuildtasks has the ( FileUpdate (and SvnVersion task if that is your Source-Control) ) tasks.
<Target Name="BeforeBuild_VersionTagIt_Target">
<ItemGroup>
<AssemblyInfoFiles Include="$(ProjectDir)\**\*AssemblyInfo.cs" />
</ItemGroup>
<!--
<SvnVersion LocalPath="$(MSBuildProjectDirectory)" ToolPath="$(SVNToolPath)">
<Output TaskParameter="Revision" PropertyName="MyRevision" />
</SvnVersion>
-->
<PropertyGroup>
<MyRevision>9999</MyRevision>
</PropertyGroup>
<FileUpdate Files="#(AssemblyInfoFiles)"
Regex="AssemblyFileVersion\("(\d+)\.(\d+)\.(\d+)\.(\d+)"
ReplacementText="AssemblyFileVersion("$1.$2.$3.$(MyRevision)" />
</Target>
Below is an example of manipulating the csproj(xml).
How to add a linked file to a csproj file with MSBuild. (3.5 Framework)
But basically, when you build, you can put all the repetative stuff in a msbuild definition file (usually with the extension .proj or .msbuild)...and call msbuild.exe MyFile.proj.
Inside the .proj file, you will reference your .sln file.
For example:
$(WorkingCheckout) would be a variable (not defined here)...that has the directory where you got a copy of hte code from your source-control.
<Target Name="BuildIt" >
<MSBuild Projects="$(WorkingCheckout)\MySolution.sln" Targets="Build" Properties="Configuration=$(Configuration)">
<Output TaskParameter="TargetOutputs" ItemName="TargetOutputsItemName"></Output>
</MSBuild>
<Message Text="BuildItUp completed" />
</Target>
So below is the more complete example.
You would save this as "MyBuild.proj" and then call
"msbuild.exe" "MyBuild.proj".
Start .proj code. (Note, I did not import the libraries for the FileUpdate Task)
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="AllTargetsWrapped">
<PropertyGroup>
<!-- Always declare some kind of "base directory" and then work off of that in the majority of cases -->
<WorkingCheckout>.</WorkingCheckout>
</PropertyGroup>
<Target Name="AllTargetsWrapped">
<CallTarget Targets="BeforeBuild_VersionTagIt_Target" />
<CallTarget Targets="BuildItUp" />
</Target>
<Target Name="BuildItUp" >
<MSBuild Projects="$(WorkingCheckout)\MySolution.sln" Targets="Build" Properties="Configuration=$(Configuration)">
<Output TaskParameter="TargetOutputs" ItemName="TargetOutputsItemName"></Output>
</MSBuild>
<Message Text="BuildItUp completed" />
</Target>
<Target Name="BeforeBuild_VersionTagIt_Target">
<ItemGroup>
<AssemblyInfoFiles Include="$(ProjectDir)\**\*AssemblyInfo.cs" />
</ItemGroup>
<!--
<SvnVersion LocalPath="$(MSBuildProjectDirectory)" ToolPath="$(SVNToolPath)">
<Output TaskParameter="Revision" PropertyName="MyRevision" />
</SvnVersion>
-->
<PropertyGroup>
<MyRevision>9999</MyRevision>
</PropertyGroup>
<FileUpdate Files="#(AssemblyInfoFiles)"
Regex="AssemblyFileVersion\("(\d+)\.(\d+)\.(\d+)\.(\d+)"
ReplacementText="AssemblyFileVersion("$1.$2.$3.$(MyRevision)" />
</Target>
</Project>
To enhance the above, you would create a new target that would run before "BeforeBuild_VersionTagIt_Target", that would pull your code from source-control and put it in the $(WorkingCheckout) folder.
The basic steps would then be: 1. Checkout code from Source-Control. 2. Run the targets that alter the AssemblyVersion (and whatever else you want to manipulate) and 3. Build the .sln file.
That's the basics of a .proj file. You can do much more. Usually by using helper libraries that already exists.