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?
Related
I'm trying to get TFS (2013) to ignore my packages folder. I passionately don't want it source controlled as I'm using NuGet and it's great!
I've tried cloaking (doesn't seem to work), I've tried adding .tfignore files - nothing is ignored. Why don't the TFS team just add an option to permanently ignore a folder or file like lots of the Subversion clients do?!
Here's the deal: We have to tell both NuGet and TFS to ignore the packages, because NuGet is trying to do source-control related stuff that it absolutely shouldn't be doing (bad form, Microsoft!). So you have to do two things.
First, add a file named .tfignore to the solution folder (note the lack of s after the tf). Its contents should be as follows:
\packages
That tells TFS to ignore your packages folder. Now, you would think that this would also ignore the repositories.config file. But it won't. Why? Who knows, the ways of Microsoft are strange and mysterious. Actually, I think it's part of the NuGet stuff I outline below, but if that ever gets fixed in the future and you want to keep the repositories.config file instead of letting VS regenerate it, you should be able to use this:
\packages
!\packages\repositories.config
OK, so now thanks to our .tfignore file, TFS is ignoring your packages. Everything is fine, right? WRONG, because NuGet is mucking around with your source control and adding the packages to your pending changes. So now let's tell NuGet to cut it out already.
Create a folder called .nuget in the root of your solution folder.1 Now, create a file called NuGet.config, and put it in this new folder2. Its contents should look like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
And now your packages should stay out of source control. Just remember to add the NuGet.config and .tfignore files to source control so they never get lost.
EDIT: If you're having issues, you may want to delete your packages folder, check in that change, and then go through the steps above.
ALSO EDIT: It looks like this won't happen with newer versions of Nuget. So maybe if you switch to VS/TFS 2017 this issue will clear up without jumping through the above hoops.
1. Add the folder using Source Control Explorer; right-click the solution->Add folder->.nuget
2. When I figured this out using VS 2013, I found the NuGet.config had to go in the .nuget folder. Even if you already have a NuGet.config file in the root of your solution folder (because, say, your company has an internal nuget feed). However, some in the comments have indicated that it works fine in the solution root in VS 2015. Personally, I switched to using TFS in git mode, so I can't test. Additionally, if you do have a custom feed, ensure that you have both the custom feed and nuget.org as keys in the Nuget.config file, or sometimes TFS will randomly decide it can't restore the packages.
An alternative solution to the above is the following.
Add the packages folder to TFS (without any files or sub-folders)
Right Click the Packages Folder
Left Click Advanced
Click Cloak
It is worth noting that this solution would need to be applied per TFS workspace. It has worked far more reliably for me rather than using the .tfignore file.
You can read more about this approach in the blog article Prevent TFS from adding installed NuGet packages to source control.
for people reporting that the .tfignore option wasn't working with the nuget.config setting it might be of interest - these steps finally worked for me:
Delete everything in my packages folder
Make sure TFS doesn't have any changes around that folder pending
Close VS
Re-open VS, and reload solution - using Nuget restore to re-populate
packages Note no changes are pending for TFS source control
Add a nuget.config file in a .nuget folder in your solution.
Add the following to the nuget.config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
The disableSourceControlIntegration is what makes the trick for TFS Version Control.
You need to be using local workspaces for .tfignore to work. The .tfignore file must be in the folder that contains the files or folders you want to ignore.
So if your solution structure looks like this:
\Project
\Packages
\OtherStuff
foo.cs
You'd put your .tfignore file in \Project:
\Project
\Packages
\OtherStuff
foo.cs
.tfignore
The contents of the .tfignore in your case would be:
\packages
Here's some documentation for you: http://msdn.microsoft.com/library/vstudio/ms245454(v=vs.110).aspx#tfignore
You can permanently set this once-off in your AppData\Roaming for all solutions (old & new)!
In your %AppData%\NuGet\NuGet.Config file, add the following just before the </configuration> XML tag...
<config>
<add key="repositoryPath" value="C:\NuGetPackages" />
</config>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
...you can specify any path you want - the important thing is putting it OUTSIDE your TFS workspace!
Now you never have to worry about that stuff again. Your solution folder will not contain any packages anymore; all solutions will default to using your custom packages location instead.
NOTE - This works is on a per-user basis.
Set your solution to restore on build, the package folder and packages file will be checked in but the packages won't.
If you are using Git with TFS you need to add a ".gitignore" file. You can do this in "team project | Settings | 'add ignore file'". Then open the file and uncomment the built in ignore statement for Nuget Packages.
If you are using TFVC and you have Local Workspaces configured you can use the ".tfignore" file that honours an identical format to the Git file. I think you need "packages/".
This didn't work for me quite on visual studio online and VS2013.
Right Click Solution > Enable NuGet Package Restore. This will add the Nuget.config file to solution
Add the .tfignore. I normally do this by adding a text file to the solution root, letting it detect that and then exclude by clicking 'detected add' > right click ignore.
Add the packages to .tfignore and tell it to include repositories.config
From the other comments it seems your milage may vary at this point. This is what I do:
Check everything in, including any packages.
Delete all packages in your solution and then check in this change (this will remove the packages from TFS)
Open the solution and build which will add the packages to the project but TFS will not pick them up.
The solution that worked for me was to create both a .tfignore and the following setting in the Nuget.Config:
<configuration>
...
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
...
</configuration>
My .tfignore contains this line:
\packages
[I'm using Visual Studio 2015 Update 2]
This is not ideal, and is currently logged as an open issue on github/nuget:
Make it easier to omit packages from TFVC #493
Terje's answer doesn't work all the time for me, sometimes it will work for a while, but then it will pend a load of "adds" for me all over again.
The only way I have found to solve this permanently is to Cloak the packages folder in my Workspace.
For example:
Type Server Local
============================================
Active $/Work/Main C:\Code\Main
Cloaked $/Work/Main/Packages
I had the same issue. /packages should work but didn't for me. packages*.* did work.
We have successfully set up a couple of local package repositories using the NuGet.Server package and hosted them on a local IIS webserver. We are able to connect from the Package Manager and install no problem. So these are working fine.
In order for us not to have to check in our packages folder we have included the following command line in each project file that includes NuGet references. This works, if the NuGet.exe is in the path on the CI build agent.
However, I would like to move the source configuration form the command line in every project file and put it in just one place, preferably where other pesky developers can't change it ;)
<Target Name="BeforeBuild">
<Exec Command="nuget install $(ProjectDir)packages.config -s
http://domain:80/DataServices/Packages.svc/;
http://domain:81/DataServices/Packages.svc/
-o $(SolutionDir)packages" />
</Target>
Is there a better way?
Yes there is ;-)
Take a look at NuGetPowerTools. After running Install-Package NuGetPowerTools, it adds a .nuget folder to your $(SolutionDir) containing nuget.exe, nuget msbuild targets and settings (which you will need to check in).
After that, you simply run Enable-PackageRestore and it sets up msbuild targets into your visual studio project files which will make sure that packages will be fetched in a prebuild step, even on your build server, without checking in any packages. (don't forget to check in the .nuget folder though!).
This way, you simply manage the nuget package sources in a nuget msbuild settings file (in the .nuget folder) central to your solution, instead of in each project.
Cheers,
Xavier
I finally got NuGetPowerTools to install after the advice from digitaltrust on http://blog.davidebbo.com
Although NuGetPowerTools solved my problem, it was overkill for what I wanted. It requires that you check in to version control a .nuget folder that it creates in your solution root. The folder contains NuGet.exe, and a couple of target files. I don't like this as I think version control is for source code, not tools.
I came up with the following solution.
Save NuGet.exe to a folder on your local drive, both on dev and continuous integration machines. I chose C:\tools\nuget\
Add that filepath to the Path Environment Variable in all environments
On continuous integration machines, find %APPDATA%\NuGet\NuGet.Config and enter the following
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="LocalRepositoryName" value="http://Domain/DataServices/Packages.svc/" />
</packageSources>
You can add more than one entry to packageSources and NuGet will search them in the order that they appear
The after build code from my question can now be amended to the following.
<Target Name="BeforeBuild">
<Exec Command="nuget install $(ProjectDir)packages.config
-o $(SolutionDir)packages" />
</Target>
The end result of this is that whenever the approved repository location is changed, the config has to be changed in only one place rather than in every csproj file. Also, it is the continuous integration server administrators who determine that location, not the developers in their command line calls.
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:-)
I have integrated MSTest with cruise control for single project by following the steps present in the below link.Its working fine
http://www.codeproject.com/KB/tips/VSTS2008_Tests_With_CCNET.aspx?display=Print.
But if i add multiple projects, the result file is getting over wrtitten by 2nd project result. I am not able to see the first project result.
Please let me know how i can display multiple project results in result fie.
... in the meantime I checked the problem in more detail and it seems that my 1st guess was right (although I didn't realize that no real build script but a simple batch is used):
Problem: A single working directory is used for all projects. Each project produces it's own results.xml file but since they are all stored in the same location results are overwritten.
Solution: Use a separate folder for the results of each project (e.g. the project's artifact directory which is passed from CruiseControl to the batch process as environment variable).
RunTests.bat:
del "%CCNetArtifactDirectory%\results.xml"
MSTest.exe /testcontainer:<PathtoTestProject>\Bin\Debug\TestAssembly.dll /resultsfile:"%CCNetArtifactDirectory%\results.xml"
ccnet.config:
<project name="ProjectA">
<cb:define projectArtifactDirectory="C:\path\to\data\of\ProjectA" />
...
<artifactDirectory>$(projectArtifactDirectory)</artifactDirectory>
...
<publishers>
<merge>
<files>
<file>$(projectArtifactDirectory)\results.xml</file>
</files>
</merge>
</publishers>
...
</project>
How can I make a project file (VS 2008) that just has some data files in and has no built output?
I can make an empty project and add my data files to it (which get copied to the output folder
), but it produces an EmptyProject.dll after I do a build. I want just my data files in the output directory and not some empty DLL or EXE.
I want the data files to be the only thing in this project as the project will be shared in a couple of solutions.
Our application is C#. All of our normal code projects are C#.
The data files are schemas (XSD). I want these schemas to be in the output folder, but I don't want them included with an existing project. I would like a project named "Schemas" that has nothing in except the XSD files and does nothing except copy the XSD files to the output folder. I would like this in a project file so that the same schemas project can be referenced in multiple solutions.
I don't know of a way to suppress the creation of the .dll file. BUT... here's an easy workaround. In the project properties, Build Events tab, write a Post-build event command line that will delete the file. Something like:
del path\filename.dll
Expanding on Scott's answer:
Create a new project of type Empty project
In Properties->Application, change Output type to Class Library
In Properties->Build->Advanced, change Debug Info to None
In Properties->Build Events, set the Post-build event command line to del $(TargetPath)
That way, the project creates only a DLL, which gets deleted. At the same time, the "copy to output directory" settings on your data files is respected.
Possibly another way is editing the csproj file by replacing this:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
with this:
<Target Name="Build" />
<Target Name="Rebuild" />
Then builds don't create anything. It worked for me.
Same general idea should work for any xxproj file. Just replace the <Import Project...> tags with the <Target...> tags.
I'd be interested in knowing if this causes any issues or doesn't work for anyone.
What do you need a project for if you're not building it?
You can use solution folders to "store" files...
Why not just disable building this project for all configurations (use the Configuration Manager) - that way it won't build.
Great stuff. Expanding on Scott > Daniel's answer:
Safe to remove all References and Properties (AssemblyInfo.cs)
If it is a node/grunt/gulp project then you can invoke it in your Build Events > *Post-build event command line * eg: gulp build or gulp clean
Perhaps you can add removal or obj and bin output folders to your node/grunt/gulp clean scripts mitigating the need for del $(TargetPath)