I'm massively miffed with this one. Here's the scenario:
I have an ant task which builds and outputs a bunch of swcs
The ant task deletes all items in the 'libs' folder, then compiles in order my libraries out outputs them to the 'libs' folder.
I have other modules that I compile that depend on these libraries
The problem: I'm having issues where a swc which depends on another swc is compiling against the old version not the one just built in the ant task.
So we compile first common.swc then mydependantswc.swc. When I compile mydependantswc.swc is compiling against common.swc - the one just built. When I compile its like common.swc has been cached, it ignores the once just build and compiles against the old version.
I know this happens in flash when you don't delete your old swc libraries before recompiling. However my ant task deletes those files. I found that on the mac if I manually went into finder and deleted those libraries off, then compiled, it works fine. Even though the ant task does that, it doesn't work.
Any ideas please? Sounds like this might be a common issue?
Here are some ant code snippets, I think its quite simple ant.
<target name="install-libraries" description="standalone build libs">
<delete includeEmptyDirs="true">
<fileset dir="${bin.dir}/${managed.libs.dest}"/>
</delete>
<mkdir dir="${bin.dir}/${managed.libs.dest}"/>
<antcall target="compile-libraries"/>
</target>
followed by a standard compc task.
After talking on twitter I suspect it has something to do with the folder structure. You see that one library has a dependency on another compiled library in this folder bin.dir, which is also the folder that I am building to. I don't know why, but i sense a smell!
Related
I'm having an issue with MSBuild ZipDirectory command, where the zipped output file differs between when built by individual project and when built for entire solution.
For example,
The expected zip file looks like below:
A.txt
B.txt
C.txt
The zipped file looks as expected when built as individual project.
However,
When solution is build as a whole,
The zipped file looks like below, missing some files:
A.txt
B.txt
What is causing such issue??
MSBuild ZipDirectory Output Different when Building Solution and
Building Individual Project
I wonder if you use ZipDirectory task to compress some certain files in your project. I have tested the command in different projects in the same solution and did not face the same issue as you said. So please check this:
1) If you just compress some content files in the project, try to create a new folder in Solution Explorer called resource and then put any files you want to compress into this. And remember to set this target executes after build process.
<Target Name="ZipOutputPath" AfterTargets="Build">
<ZipDirectory
SourceDirectory="$(MSBuildProjectDirectory)\resource"
DestinationFile="$(MSBuildProjectDirectory)\output.zip" />
</Target>
2) If you want to compress the files of the output folder, please make sure that you have set Copy to Output Directory of the specific files to Copy if newer.
Note :please check if there are some extra targets which will delete some files like C.txt or there is some extra condidtions to limit this.
Build Solution means that it can build all the projects at the same time so I wonder if some extra projects have some configuration which will cause this behavior in the first project.
3) Besides, you can also try zip task to realize this:
<Target Name="zipfiles" AfterTargets = "Build">
<ItemGroup>
<ZipFiles Include="xxxxx\A.txt" />
<ZipFiles Include="xxxxx\B.txt" />
<ZipFiles Include="xxxxx\C.txt" />
</ItemGroup>
<Zip OutputFilename="$(OutputPath)Project.zip" Files="#(ZipFiles)" />
</Target>
In addition, if all of these did not help, there might be a situation where you might have a problem with your VS environment. Due to it, you can follow these steps:
A) close VS instance, delete .vs hidden folder under the solution path,bin and obj folder. Then restart your solution and then build again to see whether the issue persists.
B) use devenv /safemode to start VS and then test whether the issue is caused by third party extensions, packages.
C) do a repair in VS Installer.
If I misunderstand your issue, please share more detailed info and feel free to let us know.
I know JarBundler is nolonger developed and doesn't work with 1.7 (link) and from the same site I found AppBundler which does produce proper .app files from jars.
I found here that the contents of these jar-apps are the same, so I did as the person suggested and only replaced the jar file inside Contents/Java (or Contents/Resources/Java in the old Jar Bundler), and it works. I could keep using AppBundler, but I'd prefer not needing an extra dependency/plugin for Ant.
Anyways, when I automate it with Ant - the .app doesn't open. I narrowed it down to this:
A .app produced from AppBundler
If I copy and paste it somewhere else, it launches
If I copy and paste it with Ant, it doesn't launch
I even tried things like clearing my application state cache, without luck. Again, the weird thing is if I copy the "source app" myself, the copy launches. If I copy the source app with Ant (and I'm doing nothing else) it doesn't.
Here's my Ant snippet (.app are just folders AFAIK) (dist.macapp is the name of the .app):
<copy todir="${dist.dir}" >
<fileset dir="${resources.dir}">
<include name="${dist.macapp}/**" />
</fileset>
</copy>
I guess I have two questions:
Why isn't this working (I think I provided enough what have I tried :P )
Is there a better way to do this (Java Web Start is out of the question, maybe something I'll look into later)
A .app file on Mac is just a standardized folder layout. You could always bundle it yourself with a script. Simply replacing the jar file isn't quite enough.
Make something like this
Contents/
Java/yourjar.jar
info.plist /* specific to your application! maybe make a template then find and replace strings */
MacOS/JavaApplicationStub
Copy the executable /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub into the MacOS folder (this is not app specific and could be done once).
I am not sure of the format for the info.plist specific to Java.
We use HEAT to build a file for our web project installer. I want to know if there is a way that I can have the file included in the compilation, but not included in the project.
The reason I need this is I would like to not check the file in on our source control, but have it build when we build the wixproj. Otherwise we have to hijack/checkout the file in order to reliably build the project.
If you are using MSBuild and a .wixproj to build your .MSI then you will need to get the output from HEAT to be listed in a Compile item in the .wixproj. If the file is not included it will not get compiled into the final .MSI.
Fortunately, MSBuild provides quite a few options to dynamically include items. For example, you could have a custom target in your .wixproj that runs HEAT and adds the output
<Target Name='RunHeat'>
<Exec Command='heat.exe param param param -o path\to\output.wxs' />
<ItemGroup>
<Compile Include='path\to\output.wxs' />
</ItemGroup>
</Target>
Now if you get the RunHeat target to run before the Compile target in wix.targets then the Compile item generated in RunHeat will be included in the Compile target. Given the flexibility of MSBuild there are probably a dozen other ways you could accomplish this task.
Hope that helps and good luck!
I am debugging a bug in my build process that happens occasionally but I can't directly reproduce it. I'm using msbuild with teamcity.
I have a dependency hierarchy like this:
Some.Interop.dll
Dependency-> SharedDllABC.dll
SomeService.exe
Depenendcy-> Some.Interop
Usually the final service exectuable gets in its release directory:
Some.Interop
SharedDllABC.Dll
ServiceExectuable.exe
However I can see in our msbuild logs that sometimes the tertiary dependency gets deleted during an Incremental Clean after everything is built resulting in:
Some.Interop
ServiceExectuable.exe
You can see it here in the msbuild log:
[src\SomeService\SomeService.csproj] _TimeStampAfterCompile
[12:32:43]: [src\SomeService\SomeService.csproj] Compile
// some other targets
[12:32:43]: [src\SomeService\SomeService.csproj] _CopyFilesMarkedCopyLocal
[12:32:43]: [_CopyFilesMarkedCopyLocal] Copy
[12:32:43]: [Copy] Copying file from "C:Projects\trunk\src\Some.Interop\bin\Release\Some.Interop.dll" to "bin\Release\Some.Interop.dll".
// some other targets
[src\Project\SomeService\SomeService.csproj] IncrementalClean
[18:54:42]: [IncrementalClean] Delete
[18:54:42]: [Delete] Deleting file "C:\Projects\trunk\src\Project\SomeService\bin\Release\SharedDllABC.dll".
[18:54:42]: [Delete] Deleting file "C:\Projects\trunk\src\Project\SomeServiceService\bin\Release\SharedDllABC.pdb".
[18:54:42]: [src\Project\SomeService\SomeService.csproj] CoreBuild
[18:54:42]: [src\Project\SomeService\SomeService.csproj] AfterBuild
[18:54:42]: [src\Project\SomeService\SomeService.csproj] Build
This is my direct msbuild output, I just changed the project names/dll names to match my example. By the time this Incremental Clean has occurred the SomeService.csproj has already been built. You can see that its not getting copied. However in other msbuild logs it does properly get copied and then the incremental clean doesn't delete it.
I think incrementeal clean from this post is supposed to clean dll's that were created from previous builds, but that doesn't explain how this dll didn't get built when most of the time it does. In visual studio this always works as well.
I guess I just want to know what exactly is Incremental clean, what causes it to kick in, and maybe what things I should look for when debugging a situation like this (assembly versions, timestamps, etc?)
Try the following:
Add:
<Target Name="IncrementalClean" />
to a .targets file that's included in all projects.
From --> https://github.com/Microsoft/msbuild/issues/1054
#Kebabbi recommends a good fix by editing a csproj file. As of MSBuild 15, there is a simple way to make this apply to all CSPROJ files, instead of editing each csproj file.
https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2017
Directory.Build.props and Directory.Build.targets
Prior to MSBuild version 15, if you wanted to provide a new, custom property to projects in your solution, you had to manually add a reference to that property to every project file in the solution. Or, you had to define the property in a .props file and then explicitly import the .props file in every project in the solution, among other things.
However, now you can add a new property to every project in one step by defining it in a single file called Directory.Build.props in the root folder that contains your source. When MSBuild runs, Microsoft.Common.props searches your directory structure for the Directory.Build.props file (and Microsoft.Common.targets looks for Directory.Build.targets). If it finds one, it imports the property. Directory.Build.props is a user-defined file that provides customizations to projects under a directory.
Create a file Directory.Build.props, and place it adjacent to the SLN file.
<Project>
<Target
Name="ForceAssignProjectConfigurationBeforeSplitProjectReferencesByFileExistence_KLUDGE"
BeforeTargets="_SplitProjectReferencesByFileExistence"
DependsOnTargets="AssignProjectConfiguration" />
</Project>
This could be caused by a bug in MsBuild: https://github.com/Microsoft/msbuild/issues/1054.
A fix is proposed in the comments: https://github.com/Microsoft/msbuild/issues/1054#issuecomment-406438561
When MsBuild determines which items to copy from referenced projects, it should do this recursively but does not properly do this.
As a workaround the following can be added to each csproj.
<Target
Name="ForceAssignProjectConfigurationBeforeSplitProjectReferencesByFileExistence_KLUDGE"
BeforeTargets="_SplitProjectReferencesByFileExistence"
DependsOnTargets="AssignProjectConfiguration"
/>
I just spent a few days trying to figure this out with a similar pattern. In our case it was nuget files that were being removed from the output folder.
NugetPackage (that drops files in x86/x64 subfolders in output folder)
LibraryA.dll
Dependency-> NugetPackage
LibraryB.dll
Dependency-> LibraryA.dll
In our case, we have a number of solution files that are built as part of an msbuild script in a certain order.
The problem was that LibraryB.csproj was included in two solution files.
Solution1 builds and output files are all present.
Solution2 builds and sees that LibraryB.dll is present and up to date, so for some reason triggers the IncrementalClean that removes the NugetPackage files from the output folder.
Once I removed the LibraryB.csproj from solution 2, the problem is solved and the files are present in the output folder.
I have a few .net / C# projects that I'm building with MSBuild.
In the project I'm building, there are some project references to other C# projects.
I'm only building individual projects, so I'd like to repoint the project references to actual binaries in a folder during the build.
I'm already setting "BuildProjectReferences" to False for my MSBuild step.
So essentially I want to have MSBuild ignore the project refs and look for those binaries in a new directory.
Is this possible to do? Is this possible without having to dynamically modify the project file prior to build?
** Update 1 **
More info might help...I'm actually building each binary via Ant/AntDotNet/MSBuild and uploading to Artifactory. I'm basically using Ivy's dependency management with .Net binaries.
Right now I have the uploads and downloads of dependencies working fine.
The only part I'm missing is getting MSBuild to look for the binaries as file dependencies instead of the project references that it has in the project file.
** Update 2 **
It looks like MSBuild supports editing the csproj file using XMLPoke and XMLPeek.
So in my case I'd need to change the following in my project file:
<ProjectReference Include="..\MyReferencedProject\MyReferencedProject.csproj">
<Project>{MyReferencedProjectGUID}</Project>
<Name>MyReferencedProject</Name>
<Private>False</Private>
</ProjectReference>
to this
<Reference Include="MyReferencedProject">
</Reference>
Can anyone give me any pointers on that?
Answer on Update2:
Your question is related/duplicate to this question. There is no easy way to convert it. You should write MSBuild custom task for it to update MSBuild project files before build.
I ended up using Ant combined with the xmltask addon.
<target name="convert" description="convert project references to file references">
<echo>Converting the following Project references :: ${Project.ItemGroup.ProjectReference.Name}</echo>
<xmltask source="MyParentProject.csproj" dest="MyParentProject.csproj">
<rename path="/:Project/:ItemGroup/:ProjectReference/:Name" to="BinaryName"/>
</xmltask>
<replace file="MyParentProject.csproj" token="<BinaryName>" value="<Reference Include=""/>
<replace file="MyParentProject.csproj" token="</BinaryName>" value=""></Reference>"/>
<xmltask source="MyParentProject.csproj" dest="MyParentProject.csproj">
<copy path="/:Project/:ItemGroup/:ProjectReference/:Reference" buffer="refbuffer" append="true"/>
<paste path="/:Project/:ItemGroup[1]" buffer="refbuffer"/>
<remove path="/:Project/:ItemGroup/:ProjectReference" />
</xmltask>
<echo>Conversion complete.</echo>
</target>
In the first xmltask we are setting the "Name" element to "BinaryName" so we can find it.
Next we have two Ant Replace tasks that change something like
"<BinaryName>MyReferencedProject</BinaryName>"
to
"<Reference Include="MyReferencedProject"></Reference>"
And in the last xmltask moves our project references we converted into file references into the upper ItemGroup that normally has the file references.
Then finally we delete the ProjectReferences section.