TFSCCNetPlugin Work Item Rss Feed

Reopened Issue: Remove call to undeclared method [12525]

martin — Fri, 14 Jun 2013 06:50:07 GMT

In the method GetSource in Vsts.cs the is a call to the method AddIntegrationProperty on the IIntegrationResult interface. This method does not exist in CCNet, it is an extension made in CIFactory, and it should be removed.

Closed Issue: Remove call to undeclared method [12525]

martin — Thu, 16 May 2013 07:48:17 GMT

Commented Issue: 1.3.1 wants 9.0 instead of 8.0 of TeamFoundation [12672]

svappaji77 — Fri, 18 Dec 2009 14:22:32 GMT

Just FYI, it looks like release 1.3.1 is looking for Version=9.0.0.0 of Microsoft.TeamFoundation.VersionControl.Client. Since I don't have TFS Orcas installed...it barfed at me. ;-)

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.TeamFoundation.VersionControl.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.TeamFoundation.VersionControl.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

~Jon
Comments: ** Comment from web user: svappaji77 **

i am getting same error even i do have vsts2010 beta with 1.4.4 sp1 install

Commented Issue: Need better error message if no access to project. [15416]

daxon — Thu, 24 Sep 2009 22:55:11 GMT

If the account that the CruiseControl service is running under does not have rights to a project (it could log into TFS, and had rights to other projects). Then the following rather unhelpful error is given:-

----------
Microsoft.TeamFoundation.VersionControl.Client.InvalidVersionSpecException: 0 is not a valid changeset number. Please specify a number greater than 0.
at Microsoft.TeamFoundation.VersionControl.Client.ChangesetVersionSpec.ValidateNumber(Int32 changeset)
at Microsoft.TeamFoundation.VersionControl.Client.ChangesetVersionSpec..ctor(Int32 changeset)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vsts.GetModifications(IIntegrationResult from, IIntegrationResult to) in C:\projects\opensource\ccnet\trunk\source\ccnet\ccnet.vsts.plugin\Vsts.cs:line 160
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResult thisBuild)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.Project.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Integrate()
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Run()

---

We should give a better error message. In the meantime, the work-around is to give the CruiseControl.NET account rights to that project.
Comments: ** Comment from web user: daxon **

Got the same error today with a reference to a source control location that did not exist.

Commented Issue: TFS plugin does not work when running ccnet as a 64 bit process [14722]

rhencke — Tue, 15 Sep 2009 15:39:14 GMT

I don't know exacly who owns the problem, but people will say that the "TFS plugin does not work" so here goes.

The TeamFoundation assemblies that the TFS Plug-in uses are marked as Win32 only. They will not load in a 64 bit process. The exception will say that Microsoft.TeamFundation.VersionControl.Client can not be loaded.

The workaround to to set the 32 bit flag on ccnet.exe/ccservice.exe like this:

corflags /32bit+ ccnet.exe

But it would be nice to atleast get a better errormessage so you know what is going on
Comments: ** Comment from web user: rhencke **

This saved me from a big headache! Thank you!

Commented Issue: Need better error message if no access to project.

kerbou — Thu, 13 Aug 2009 10:06:41 GMT

For your information: I got this error as well today but in a totally different context: If you make i.e. a spelling mistake in the <project> tag under <sourcecontrol> you get the exact same errormessage... I was chasing ghosts for an hour before I realized that "$blabla\somethingServer" isn't the same as "$blabla\somethingService" ;o)

Commented Issue: Exclusion Support

Yogendrap — Wed, 03 Jun 2009 10:13:45 GMT

I'm using a source control block like this:

{{
<sourcecontrol type="filtered">
<sourceControlProvider type="vsts" autoGetSource="true">
<server>http://myserver:8080</server>
<project>$/My/Path</project>
<workingDirectory>C:\My\Build\Path</workingDirectory>
<cleanCopy>true</cleanCopy>
</sourceControlProvider>
<exclusionFilters>
<pathFilter><pattern>**/Documentation/**</pattern></pathFilter>
<pathFilter><pattern>**/Spikes/**</pattern></pathFilter>
</exclusionFilters>
</sourcecontrol>
}}
This kind of config works with Subversion (the exact same exclusions prevent automated build) but since moving to TFS, the exclusions aren't working any more.

Any clues on what it takes to make this work?
Comments: ** Comment from web user: Yogendrap **

Please check your path, it is case sensitive by default.
or use the following,

<pathFilter>
<pattern>$/yourprojectpath/**/*.config</pattern>
<caseSensitive>false</caseSensitive>
</pathFilter>

Created Issue: Update NetReflector reference to 1.1.2009.1004

lewismoten — Fri, 24 Apr 2009 19:47:49 GMT

This plug-in is no longer compatible with 1.4.4.27+ of CruiseControl.net

Event Type: Error
Event Source: CCService
Event Category: None
Event ID: 0
Date: 04/24/2009
Time: 2:02:35 PM
User: N/A
Computer: LMOTEN-3
Description:
Service cannot be started. System.IO.FileLoadException: Could not load file or assembly 'NetReflector, Version=1.0.0.120, Culture=neutral, PublicKeyToken=2f4dd8b32acbcd8e' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'NetReflector, Version=1.0.0.120, Culture=neutral, PublicKeyToken=2f4dd8b32acbcd8e'

Server stack trace:
at System.ModuleHandle.ResolveType(Int32 typeToken, RuntimeTypeHandle* typeInstArgs, Int32 typeInstCount, RuntimeTypeHandle* methodInstArgs, Int32 methodInstCount)
at System.ModuleHandle.ResolveTypeHandle(Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)
at System.Reflection.Module.ResolveType(Int32 metadataToken, Type[] genericTypeArguments, Type[] genericMethodArguments)
at System.Reflection.CustomAttribute.FilterCustomAttributeRecord(CustomAttributeRecord caRecord, MetadataImport scope, Assembly& lastAptcaOkAssembly, Module...

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Created Issue: Need to have failed return when source code not pulled down

SirCodeAlot — Tue, 07 Apr 2009 20:35:33 GMT

In my case, we had a file checked out in the workspace (definetly our fault), however when the plugin could not pull down source (under any circumstances) it should fail the build.

Created Issue: Need ability to get the latest source when building instead of latest changeset

sdedios — Tue, 03 Mar 2009 14:39:20 GMT

Currently the TFS Plug-in for CruiseControl.NET checks for the modification of changesets based on datetime ranges determined by the CC.NET server. During this process the most recent changeset is cached and used to retrieve the source to build.

This process can be problematic, especially when the TFS server time is out of sync with the build server time. This can be extremely risky for release builds. For instance, if the build server time is behind the TFS server a release build could be started but code that was checked in within the window of time difference would not make it into the release build.

There should be a way to force the plug-in to get the latest source (similar to the VSS plug-in).

Commented Issue: Need better error message if no access to project.

OwenCarter — Tue, 28 Oct 2008 16:22:07 GMT

This error is also seen if you try to set the <project> definition within a <sourcecontrol type="vsts" ...> block to a non-existant path;

We had <project>$/YEP/Main/</project> in our sourcecontrol block, which was a typo since this path does not exist (but $/YEP/Maint does) in the TFS Sourcecontrol. We saw the above errors (and wasted a lot of time debugging it as a access-rights issue) until noticed and corrected it to: <project>$/YEP/Maint/</project>, at which point everythign sprang into life..

So this is an error that really translates to:
You have access to the TFS server, but not to the requested source control item(s). Either due to permissions on the items, or because they do not exist..

Commented Issue: TFS plugin does not work when running ccnet as a 64 bit process

anilk — Thu, 09 Oct 2008 12:39:09 GMT

Yes, thanks for the tip. A life saver!
-Krip

Commented Issue: TFS plugin does not work when running ccnet as a 64 bit process

bhehe1 — Fri, 03 Oct 2008 21:16:06 GMT

Wow. I think this might have just solved my problem after a day long fight. I'm sort of embarrassed for the CC.NET team... Who ever works on that installed - they really should do a 'detect x64' routine and warn people about this simple fix... or better yet.... just go ahead and bundle the corflags.exe tool and do this as part of the install. Is there any reason someone wouldn't want to do this? At the minimum detection and bringing up a window of known issues related to x64 installation would have been helpful.

Closed Issue: Special Characters in source files being mutilated

martin — Mon, 11 Aug 2008 19:00:57 GMT

This happens with either 1.3 or 1.4 CC.NET and the 1.4 release (TFS 2008) version of the plug-in. In our resource files the copyright characters and a few other special characters are being transposed to gibberish if the source is pulled down through the PlugIn. If I use Visual Studio it actully gets pulled down correctly and in tact, so it has to be something in the plugin. By the way we have Visual Studio 2008, but our TFS server is still 2005 in case this is part of it.
Comments: Error was with actual source files being managed, not the plug-in.

Commented Issue: Special Characters in source files being mutilated

martin — Mon, 11 Aug 2008 19:00:15 GMT

Cool - thanks very much for letting me know!

Commented Issue: Special Characters in source files being mutilated

SirCodeAlot — Mon, 11 Aug 2008 14:45:24 GMT

Martin,
So I went to set up a demo file with all the characters so I could send you the two files for comparison. However, this file did not get jacked. So I started investigating the differences in the file I created, and the ones that were already in source and getting mutilated. What I found is, the ones getting mutilated were encoded in UTF-8, now Visual Studio would display them correctly and synch them correctly. But if I took those same files that had been synched "correctly" through the GUI (The ones where you would actually see the copyright symbol in VSTS) and looked at those files in Word they would be changed in the exact same manner as they had been coming through the plugin. So in short I do not think this is a plugin issue, I think it is our issue with the way we were encoding our RC files, but that fact had been hidden by VSTS and notepad knowing how to display something, even if it probably shouldn't have been displayed. Sorry for bothering you and thanks for your time..And a great plugin ;)

Commented Issue: Special Characters in source files being mutilated

martin — Mon, 04 Aug 2008 13:31:32 GMT

Wow. Really don't understand what might be doing this. The plug-in is calling the same .NET API that Visual Studio calls to do the file download etc. Would it be possible to replicate this problem with a couple of files (one in Visual Studio and one with the same file pulled down from the plug-in) and then attach them to this work item. I'll then do a byte-by-byte diff of the files to see what is different between them. Sounds to me like it might be a file encoding issue or something - very strange.

If you can let me know which locale you are running the plug-in in as well that may help.

Thanks for reporting this.

Martin.

Created Issue: Special Characters in source files being mutilated

SirCodeAlot — Fri, 01 Aug 2008 16:38:46 GMT

COMMENTED ISSUE: Exclusion Support

omicronbp — Thu, 08 May 2008 18:13:27 GMT

would love to see this implemented if anyone is still working on this project.

COMMENTED ISSUE: TFS plugin does not work when running ccnet as a 64 bit process

BradWilson — Tue, 04 Mar 2008 20:50:41 GMT

IMO, the right fix for this is to stop using the TFS libraries and instead talk directly to the TFS web service APIs. The source control APIs are not overly complicated. This would also allow you to mainline the TFS plugin into the CCnet builds since it won't rely on any 3rd party APIs.