I am sure there is a simple answer to this, but my google-fu fails me.
I have a team project in TFS 2008 that builds OK when using the latest code, however I now have a need to fetch the previous versions of a subset of the files at build time. The subset of files are all labeled with the same label ("MyLabel" in the snippet below).
The snippet of XML I have added to be TFSBuild.proj file looks like this:
<PropertyGroup>
<BuildLabel>LMyLabel</BuildLabel>
</PropertyGroup>
<Target Name="BeforeCompile">
<Get
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
Condition=" '$(SkipGet)'!='true' "
Workspace="$(WorkspaceName)"
Recursive="$(RecursiveGet)"
Force="$(ForceGet)"
Version ="$(BuildLabel)"
Preview="false"
/>
</Target>
This successfully fetches the subset of files into the source area, however it also deletes all other files in the source area.
i.e. the build process does the following:
fetch latest versions of all files into the source area
fetch labeled version of subset of files into the source area
delete all non-labeled files from the source area
run build
The build fails with the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(997,5): error MSB3491: Could not write lines to file "[build directory]\Sources\MySolution.sln.x64.Release.vsprops". Could not find a part of the path '[build directory]\Sources\MySolution.x64.Release.vsprops'.
(which basically indicates that it can't find the solution, because it's been deleted)
I've tried adding the following snippet to the bottom of the XML:
<PropertyGroup>
<SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet>
</PropertyGroup>
</Project>
but the result is the same.
So, my question is: how do I build my solution when it is a mixture of latest versions and older, labeled versions? What am I missing?
(I realize I could just branch the baseline but for various reasons I would like to explore this approach first)
Thanks in advance!
Just a simple approach that come to mind:
Get your latest version to workspace1
Get your labeled version to workspace2
XCopy workspace1 content over workspace2 as a post-get action
What do you think? Worth the try?
Looking at C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets, it appears that the version fetched for the build is controlled by the GetVersion property. And that ForceGet is true by default.
I haven't tested it, but that implies to me that if you put
/property:GetVersion=*versionspec*
in the MSBuild Command Line Arguments textbox when you queue the build, it should fetch the specified version (look here for versionspec syntax. If this fails for some reason, read Aaron Hallberg's blog until you understand msbuild better than I do:-)
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've created an MSBuild proj file that contains the following header:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="12.0" TargetFrameworkVersion="4.5" VisualStudioVersion="VersionLatest">
This proj file is used to trigger an MSBuild on a number of SSDT projects, couples with a Deploy.
For most developers, this is fine. However, one dev encounters a Deploy72002 exception when trying to run the build. According to this answer, this is due to the VisualStudioVersion not being set. Sure enough, adding
set VisualStudioVersion="12.0"
in the batch file prior to the MSBuild call fixes the problem.
However, I was under the impression (I can't find the source now) that setting VisualStudioVersion="VersionLatest" in the xml of the proj file was sufficient to make it use the highest version of VS installed. I've even tried setting it from VersionLatest to 12.0, and also moving it from the root node, into a node of it's own in <PropertyGroup>.
I'd rather not have a hardcoded reference to 12.0 in the batch file. Am I missing something obvious to make VersionLatest work?
Try this: run MsBuild with the command line option to generate a preprocessed single file. Do the same on a working computer with the same version. Diff the files produced.
It might be picking up different contents for some .props or .targets file. These have been known to change due to installing or updating some or another. I recall following a msdn article to fix such a file when I looked up a problem.
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 started using ccnet to build my project. This is quite new issue for me so I have some problems.
First thing: Why does ccnet copy directory with my project to another directory (ccnet creates new folder named the same as project name included in ccnet.config file and copies to them directory with my project)
Second thing: Dashboard page cannot show reports for recent build (When I click on any item in recent build then I get page: "The page Cannot be found" I suppose that page cannot link files with logs. but I don't know how to link it.
I create one publisher:
<publishers>
<xmllogger logDir="c:\Branches" />
Can anyone help me?
Just a question, does the batch file "C:\Branches\Scripts\Build Release.bat" perform that step?
Because I can't see anything obvious within the CruiseControl config to copy the files into "c:\Program Files\CruiseControl.NET\Sever\TestProject"...
In build Release script I just call devenv to compile my project
Not sure I fully understand the 'first thing' if you can elaborate on it I'll try to help.
On our system it performs an SVN checkout of the code to a specified location and builds it there. Even though our CCNet installation is on the same box as the SVN repository it still needs somewhere separate to build the project.
On the 'second thing' it sounds like you have not set the <webURL> element properly - not a major problem. If you can post your config file that may help (with both issues).
Our CCNet installation pretty much worked out of the box but it is pretty fussy about it's config files. Have you made any changes to the dashboard.config file or is it as installed?
[Edit in response to posted config file]
I can't see anything in this config that will cause CCNet to copy the project to c:\Program Files\CruiseControl.NET\Server\TestProject. It could be something to do with the way you are calling devenv in your batch file - do you specify any paths in there?
Based on your config file and assuming you have an out of the box installation, your <webURL> element should read something like this:
<webURL>http://localhost/ccnet/server/local/testProject/ViewProjectReport.aspx</webURL>
On top of all that I would highly recommend that you drop the use of .bat files and devenv.exe for building your projects. Although this is the way I started with CCNet I quickly found that using NAnt and MSBuild well worth the effort.
I Try explain it more.
I have my local copy of repository on the path: "c:\Branches\trunk"
here is my config file:
<cruiseControl>
<project name="testProject">
<webURL>http://localhost/ccnet/</webURL>
<triggers>
<intervalTrigger name="interval trigger" seconds="600" initialSeconds="30" />
</triggers>
<sourcecontrol type="svn" autoGetSource="true">
<trunkUrl>http://********/svn/general/provider/prototype/Trunk</trunkUrl>
<workingDirectory>C:\Branches\Trunk</workingDirectory>
<password>***********</password>
<username>*************</username>
</sourcecontrol>
<tasks>
<exec>
<description>Compile program</description>
<baseDirectory>C:\Branches\Trunk\</baseDirectory>
<buildTimeoutSeconds>9000</buildTimeoutSeconds>
<executable>C:\Branches\Scripts\Build Release.bat</executable>
</exec>
</tasks>
<publishers>
<xmllogger logDir="C:\Branches\Trunk\Logs" />
</publishers>
<state type="state" directory="C:\Branches\Trunk\Logs"></state>
</project>
</cruisecontrol>
I didn't change anything in dashboard.config File.
cnet copy all folder c:\Branches\Trunk
to new folder c:\Program Files\CruiseControl.NET\Sever\TestProject
First problem was cause because in previous version of config file i use filesystem as sourcecontrol. Right now this problem don't occur.
Second problem is not resolved, But I have one Idea, Does any configuration files should be placed in virtual directory?
I've added a pre-build action for an ASP.NET web control (server control) project, that runs jsmin.exe on a set of Javascript files. These output files are part of the source control tree and are embedded into the assembly.
The problem is when the pre-build runs, jsmin can't write the file as it's readonly. Is it possible to check the file out before hand? Or am I forced to set the file's attributes in the command line.
Any improved solution to the problem is welcome.
Update
One small issue with Mehmet's answer -you need to prepend the VS directory:
"$(DevEnvDir)tf" checkout /lock:none "$(ProjectDir)myfile"
If you're using Team Foundation Server, you can use team foundation command line utility (tf.exe) to check out the file(s) during pre-build and then check them back in during post-build. If you're using something else for source control, you can check if they have a command line tool like tf.exe.
If you do not want to check the files in as part of the build (which you normally wouldn't for this sort of thing) then I would simply set the attributes of the .js files before running jsmin on them. The easiest way of setting the files read-writeable is to use the the Attrib task provided by the MSBuild community extensions. The same community extensions also provide a JSCompress task for easily calling JSMin from MSBuild.
Therefore you'd have something like the following (not tested):
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<!-- rest of TFSBuild.proj file -->
<Target Name="AfterGet">
<Message Text="Compressing Javascript files under "$(SolutionRoot)"." />
<CreateItem Include="$(SolutionRoot)\**\*.js">
<Output TaskParameter="Include" ItemName="JsFiles"/>
</CreateItem>
<Attrib Files="#(JsFiles)" ReadOnly="false"/>
<JSCompress Files="#(JsFiles)" />
</Target>
Note that by modifying the files after getting them may well cause issues if you tried to move to an incremental build.