Microsoft Ajax Minifier 4, how to change output folder? - c#

I would like to change the output folder of the ajax minifier so that when i build my project, all javascripts end up in the output folder instead of a copy next to the original file.
<Import Project="$(MSBuildExtensionsPath)\Microsoft\MicrosoftAjax\ajaxmin.tasks" />
<Target Name="AfterBuild">
<ItemGroup>
<JS Include="SourceScripts\*.js" /> <!--Output="Scripts\*.js"-->
</ItemGroup>
<ItemGroup>
<CSS Include="**\*.css" Exclude="**\*.min.css" />
</ItemGroup>
<AjaxMin
JsSourceFiles="#(JS)" JsSourceExtensionPattern="\.js$" JsTargetExtension=".min.js"
CssSourceFiles="#(CSS)" CssSourceExtensionPattern="\.css$" CssTargetExtension=".min.css" />
</Target>
Something like this. I have one folder called SourceScripts and one mirrored folder called Scripts. When i build, i want the scripts in SourceScripts (and its folders) to be minified and copied to the Scripts folder (same folder structure). Is this possible?
We are using VS 2010.

Related

Move Folder - csproj and Nuget

I have a nuget getting created and Content folder getting created in the nuget. I want my files to not be in Content folder but be in the Test folder in that nuget. (So, user won't see files by default.)
How Can I move files from ContentFolder to Test folder ?
My csproj has :
<ItemGroup>
<Protobuf Include="*.proto" GrpcServices="Both" />
<Content Include="#(Protobuf)" /> // If I remove this line - Content folder disappers, but I want to keep this data into a Test folder in my nuget
</ItemGroup>
You can use PackagePath to control where content is placed in NuGet packages.
<ItemGroup>
<Protobuf Include="*.proto" GrpcServices="Both" />
<Content Include="#(Protobuf)" PackagePath="Test" />
</ItemGroup>

MSBuild in Visual Studio - Moving files before including them as content (C#)

I have a C# project which has two C++ .dll versions with the same name but differ based on their architecture (32-bit or 64-bit), they are stored in separate folders and must have the same name, I want to include the right file with that name.
So the plan is to first check the current platform when building, copy the right file from the right folder (based on the platform) into the project directory and then include that file as content to the project so it can be used.
<ItemGroup>
<Source32Bit Include="File_32bit\File.dll" />
<Source64Bit Include="File_64bit\File.dll" />
</ItemGroup>
<Target Name="CopyFiles" BeforeTargets="Build" >
<Copy SourceFiles="#(Source32Bit)" DestinationFolder="$(ProjectDir)" Condition=" '$(Platform)' == 'x86' " />
<Copy SourceFiles="#(Source64Bit)" DestinationFolder="$(ProjectDir)" Condition=" '$(Platform)' == 'x64'" />
</Target>
<ItemGroup>
<Content Include="File.dll">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>
</ItemGroup>
But if I run this then it tries to perform Content Include before the Target "CopyFiles" has run and so it cannot find the File.dll in that directory. If I make a target for this content include and try to do AfterTarget="CopyFiles" it complains about the CopyToOutputDirectory.
How should I handle this? Any ideas? Thanks!
But if I run this then it tries to perform Content Include before the
Target "CopyFiles" has run and so it cannot find the File.dll in that
directory. If I make a target for this content include and try to do
AfterTarget="CopyFiles" it complains about the CopyToOutputDirectory.
The main reason is that Build target executes later than MSBuild to read the Item elements, so when you perform the copy operation, it is already later than reading the Item elements, so the project cannot find the copied file. Therefore, you only need to execute the CopyFiles target before reading the Item elements.
So I found a system target called FindInvalidProjectReferences which executes earlier than reading Item elements.
Solution
Try these:
<ItemGroup>
<Source32Bit Include="File_32bit\File.dll" />
<Source64Bit Include="File_64bit\File.dll" />
</ItemGroup>
<Target Name="CopyFiles" BeforeTargets="FindInvalidProjectReferences">
<Copy SourceFiles="#(Source32Bit)" DestinationFolder="$(ProjectDir)" Condition=" '$(Platform)' == 'x86' " />
<Copy SourceFiles="#(Source64Bit)" DestinationFolder="$(ProjectDir)" Condition=" '$(Platform)' == 'x64'" />
</Target>
<ItemGroup>
<Content Include="File.dll">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>
</ItemGroup>
Note: when you first load the project, the test.dll has a yellow triangle which is a normal behavior because you did not build your project. And it needs the build process first.
You should build your project first and it will not turn out any errors and when the test.dll in Solution Explorer will not have the warning symbol.
This answer works with Visual Studio 2022.
If you want to use globs (**/*) to pick up generated files as <Content>, then define the fileset and <Content> twice - once at the project level, and once again inside the target that generates the files.
The first time the project builds, the project-level <Content> picks up zero files, but the target-level <Content> picks up produced files.
For later builds, both <Content> elements pick up the files, and that's harmless.
<ItemGroup>
<MyOutputFiles Include="where\output\was\generated\**"/>
<Content Include="#(MyOutputFiles)" CopyToOutputDirectory="PreserveNewest" Link="specific\out\dir\%(RecursiveDir)%(Filename)%(Extension)"/>
</ItemGroup>
<Target Name="GenerateMyFilesPlz" BeforeTargets="BeforeBuild">
<Exec Command=""$(ProjectDir)..\TheTool\TheTool.exe" some args" />
<ItemGroup>
<MyOutputFiles Include="where\output\was\generated\**"/>
<Content Include="#(MyOutputFiles)" CopyToOutputDirectory="PreserveNewest" Link="specific\out\dir\%(RecursiveDir)%(Filename)%(Extension)"/>
</ItemGroup>
</Target>
This is particularly more desirable than FindInvalidProjectReferences because
it runs only when you build. (FindInvalidProjectReferences tends to be invoked by Visual Studio whenever it feels like it)
it makes reasonable error messages when it fails. (when BeforeTargets="FindInvalidProjectReferences" fails, you get a thousand errors like "I can't find Newtonsoft.Json!" because no project references were resolved.)
it works the same whether building via Visual Studio or via dotnet build on the command line. (I've had mixed results with FindInvalidProjectReferences)
it allows the use of globbing (**/*) to define the fileset
Can you rename the path in which the DLL files reside?
If instead of naming those folders File_32bit and File_64bit, you can name them File_x86 and File_x64.
Then you could have ItemGroup:
<ItemGroup>
<Source32Bit Include="File_$(Platform)\File.dll" />
<Source64Bit Include="File_$(Platform)\File.dll" />
</ItemGroup>
Note: I don't really know if this works.

Add a directory to clickonce

I want to add a directory and its files to visual studio keeping the root dir. I did this with the below piece of XML on my .csproj file but this does add all its files to solution explorer but exclude the root. The file are variable and I don't want to hard code them add manually. That's why I'm looking for an automated solution.
How do I fix this?
<ItemGroup>
<Content Include="bin\x86\release\myFolder\**\*">
<Visible>true</Visible>
<Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
</Content>
I would like to include this directory (and not only its files) in ClickOnce publishing.
I couldn't think of any automatic way to created the folder and make the solutin explorer aware of this files. So I created the folder on right click on project -> add folder. Unloaded the project and edited the piece of XML which add the directory I've created to solution explorer to this:
<ItemGroup>
<Content Include="foo\*.*">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<Visible>True</Visible>
</Content>
</ItemGroup>
Now solution explorer is aware of that files and so does clickonce. The files get properly in the app.publish folder
NOTE: On this project, the foo files came from another folder (external C++'s binary output folder). They're copyed at post-build time. The folder name is sort of hard-coded (I need to chage them manually on the VS solution explorer, on the .csproj file and in the xcopy command-line on post-build) cause I didn't find any other way to do that.
<Target Name="AddGeneratedFiles" AfterTargets="SOMETASK">
<CreateItem Include="*.cpp">
<Output TaskParameter="Include" ItemName="ClCompile" />
</CreateItem>
</Target>

MSBuild task does not cause generated c# files to compile

I've been trying to write an MSBuild task to "compile" CoCo/R .ATG files into C# files which will then get compiled into the executable, this is to replace the pre-build event.
I've managed to get the .ATG -> .cs process working, however something is not right since the generates .cs files do not get compiled.
If I then modify the .ATG file again, the "old" .cs files seems to get compiled then new ones generated.
I'm quite sure I'm missing something that will inform the rest of the build process that these files have changed.
Here is the target definition that I have included in my Visual Studio 2010 project.
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<AvailableItemName Include="BuildATG" />
</ItemGroup>
<PropertyGroup>
<CoreBuildDependsOn>
BuildATGTarget;
$(CoreBuildDependsOn)
</CoreBuildDependsOn>
</PropertyGroup>
<Target Name="BuildATGTarget" Inputs="#(BuildATG)" Outputs="#(BuildATG -> '%(RelativeDir)Parser.cs')">
<Exec Command="Coco.exe %(BuildATG.Identity)" Outputs="%(BuildATG.RelativeDir)Parser.cs" />
</Target>
</Project>
I am completly new to MSBuild, so any advice / pointers would be appreciated.
One possible solution I have found is to do the following changes and add an ItemGroup inside the target.
<Target Name="BuildATGTarget" Inputs="#(BuildATG)" Outputs="#(BuildATG -> '%(RelativeDir)Parser.cs')">
<Exec Command="Coco.exe %(BuildATG.Identity)" Outputs="%(BuildATG.RelativeDir)Parser.cs" />
<ItemGroup>
<Compile Include="%(BuildATG.RelativeDir)Parser.cs" />
<Compile Include="%(BuildATG.RelativeDir)Scanner.cs" />
</ItemGroup>
</Target>
To avoid duplicate files in your build, you also need to mark the files (Parser.cs and Scanner.cs) in the Visual Studio 2010 project with Build Action: None

ABCpdf nuget package XULRunner folder is corrupt?

I'm trying to update my (previously working) pdf-creating web application to use the ABCpdf.NET and ABCpdf.NET Gecko Runtime nuget packages.
I've installed both packages (both are version 8.1.1.6) however when I run my application, I get the following WebSupergoo.ABCpdf8.Internal.PDFException:
Failed to add HTML: Gecko engine hit an error it was unable to recover
from. Possible causes: XULRunner folder is corrupt or is from another
version of ABCpdf.
After installing the ABCpdf.NET Gecko Runtime package, I got a dialog telling me that I would need to manually copy the XULRunner folder into my output directory. In order to achieve this, I added the following to my applications .csproj file:
<Target Name="AfterBuild">
<CallTarget Targets="CopyAbcpdfToDeployFolder" />
</Target>
<Target Name="CopyAbcpdfToDeployFolder">
<ItemGroup>
<SourceDir Include="$(ProjectDir)XULRunner\**\*.*" />
</ItemGroup>
<Copy SourceFiles="#(SourceDir)" DestinationFolder="$(WebProjectOutputDir)\$(OutputPath)%(SourceDir.RecursiveDir)\XULRunner" />
</Target>
(This seems to be working correctly - the XULRunner folder and its contents are present in my bin folder after a build)
The line of code that is failing is as follows:
theDoc.AddImageUrl(url);
Can anyone help me get this working?
As it turns out, my changes to the .csproj file we not copying all files into the correct subfolders. In order to copy the folder structure and files recursively, the XML should have looked like this:
<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>
I was able to accomplish the same outcome with the following MSBuild xml:
<ItemGroup>
<Content Include="XULRunner\**\*.*">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
I fell upon this setup after dealing with issues concerning the building of a package via MSDeploy not including the XULRunner files.
Not sure if there's anything patently wrong with this, but so far it works for me on a multiple staged deployment setup.

Categories

Resources