TFSCCPolicy Work Item Rss Feed

Created Issue: VS 2012 Support [33497]

knoxi — Fri, 30 Nov 2012 11:44:15 GMT

Hi
Did you plan to add support for VS 2012?

Created Issue: Failed Parsing File [32688]

knoxi — Thu, 10 May 2012 10:43:09 GMT

Hi
On certain files, the error "Failed Parsing File ..." occurs during check-in.
We detected that this appears when a character is duplicated in a file:
e.g.
twice :: -> using global::SpaceClaim.Api.V9;
twice "" -> string text = String.Format("Size: ""{0}mm""", this.Width);

Could you please check your parser and fix it?

Thanks.

Demian

Created Issue: Operator overloading not considered [26574]

Scordo — Thu, 25 Mar 2010 12:29:33 GMT

Hello,

can you please implement support for checking operator overloads :)
Code like this is not considered by the policy:

public static explicit operator Property(PropertyProxy objPropertyProxy)
{
Property objProperty;

objProperty = new Property();
for (int n = 0; n < objPropertyProxy.DetailList.Count; n++)
{
objProperty.Add((Detail)(objPropertyProxy.DetailList[n]));
}
return objProperty;
}

Would be really nice to have it a later release.

Thanks,
Jens

Created Issue: Enforce policy only on certain types of changes

tbeerley — Wed, 17 Sep 2008 19:39:02 GMT

On a large existing codebase, turning this policy on is very disruptive. It would be nice if I could specify that the policy should only be applied to new files. That way, at least the problem doesn't get any worse and I can gradually go back to all the old code to add comments.

This could be done by adding options to the configuration dialog, which would correspond to each of the different change types which is exposed by the PendingChange class (e.g. PendingChange.IsAdd, PendingChange.IsEdit, etc.).

Created Issue: Dataset auto-generated code getting checked...

DameonAngel — Thu, 04 Sep 2008 20:55:53 GMT

Hi, I have a problem with my custom auto-generated dataset files getting checked for comments.
My custom add-on takes the normal dataset designer files, tears them apart, and fits them back together into a better dataset.

Is there any way this policy could check for the "DebuggerNonUserCodeAttribute" and not check those?

I can't use a namespace to filter out what is checked because the namespace should be checked for partial dataset additions.

CREATED ISSUE: Only modified code is checked

ChristophWille — Thu, 03 Apr 2008 12:36:28 GMT

Hi,

it would be nice if CCCP would not only check modified code but also already existing code.

Alex

COMMENTED ISSUE: Eliminate dependency DLLs in GAC

ChristophWille — Thu, 29 Nov 2007 13:28:14 GMT

We have a batch file & exe combination which automatically creates a workspace to our CommonCode folder, gets all the custom check-in policies, and then calls the exe which adds the registry entry for each dll in the folder into the registry.

This works fine with other custom check-in policies, but not for this one. This is because the CCCPPol.dll depends on CCCPLib & NRefactory components and requires them installed in the GAC. Can something be done about this to support the deployment model above?
Comments: ** Comment from web user: ChristophWille **

Problem is, when the policy is loaded, it won't be able to load assemblies that live next to it in the same folder (at least for VSTS2005 this was the case, and that's why those three assemblies are installed in the GAC).

CREATED ISSUE: Class comment not found if attributes in regiones

sockenfresser — Fri, 09 Nov 2007 09:28:18 GMT

The class comment is not found if the class attributes are contained in a "#region".

This sometimes is necessary to hide the attributes, if you have a lot of them.

Try this example:

using System;
using System.Collections.Generic;
using System.Text;

namespace Hermos.ESystem.V3.Modules.Customer
{
/// <summary>
/// Do you know what CCCP means in Cyrillic?
/// </summary>
#region a lot of Attribute stuff
[Serializable()] //
#endregion
public class CCCPTest
{

}
}

CREATED ISSUE: Eliminate dependency DLLs in GAC

Chandalar — Wed, 24 Oct 2007 21:08:06 GMT

CLOSED FEATURE: Check Only Projects X, Y, Z

ChristophWille — Thu, 19 Jul 2007 15:00:15 GMT

The code comment checking policy currently checks all source code files that are being checked in based on a rather simple logic inside method CCCPTfsPolicy::IsVerifyableFileType.

However, it would be desirable to *exclude* certain projects from checking. The reasoning is that class libraries are a good candidates for checking proper code commenting, whereas eg a quick-and-dirty VB Winforms frontend checked into the same team project doesn't need code comments at all.

Things to be evaluated: is there a way in the checkin policy to find out which file belongs to which project? Or would we need to track this based on directories and mapped workspaces?
Comments: Implemented as "Included Paths" feature in v2.1

CLOSED FEATURE: Exclude Namespaces

ChristophWille — Thu, 19 Jul 2007 14:59:36 GMT

Do not check classes that live in excluded namespaces. Why would you exclude a namespace? Autogenerated code eg.
Comments: Implemented in v2.1

CLOSED FEATURE: MSBuild Task for CCCP

ChristophWille — Thu, 19 Jul 2007 14:59:17 GMT

The MSBuild task will enable the following:

* calculating the "comment coverage"
* outputting a detailed list of methods, etc that don't have proper code comments
* possible to run it as part of Team Build

Comment coverage is already being tracked inside cccplib, the functionality hasn't been surfaced so far though. The output format of all three feature areas needs to be discussed, ideally it should be similar to what NUnit outputs.
Comments: Implemented in v2.0

CREATED FEATURE: Exclude Namespaces

ChristophWille — Thu, 19 Jul 2007 14:59:01 GMT

Do not check classes that live in excluded namespaces. Why would you exclude a namespace? Autogenerated code eg.

COMMENTED FEATURE: Check Only Projects X, Y, Z

RyanHaney — Fri, 02 Feb 2007 03:56:44 GMT

The code comment checking policy currently checks all source code files that are being checked in based on a rather simple logic inside method CCCPTfsPolicy::IsVerifyableFileType. However, it would be desirable to *exclude* certain projects from checking. The reasoning is that class libraries are a good candidates for checking proper code commenting, whereas eg a quick-and-dirty VB Winforms frontend checked into the same team project doesn't need code comments at all. Things to be evaluated: is there a way in the checkin policy to find out which file belongs to which project? Or would we need to track this based on directories and mapped workspaces? Comments: ** Comment from web user: RyanHaney **

This is a GREAT idea. We currently get warnings from FX-Cop but this doesn't preclude us from checking items into TFS, which should be a policy. Our commenting goal is only aligned with custom framework related libraries, as multiple programming groups within our organization use it. 10 votes from me!

CLOSED TASK: Virtual and Abstract Members Ignore Option

ChristophWille — Mon, 22 Jan 2007 13:59:48 GMT

Add option to not check virtual or abstract overrides. Base class provides documentation for those. Sample: public class BaseClass { public virtual SomeMethod() } public class DerivedClass:BaseClass { public override SomeMethod() } Same goes for abstract classes (might be hard to do). Comments: Resolved with changeset 16809.

CREATED TASK: Virtual and Abstract Members Ignore Option

ChristophWille — Mon, 22 Jan 2007 10:17:38 GMT

CREATED FEATURE: Check Only Projects X, Y, Z

ChristophWille — Sun, 21 Jan 2007 13:59:22 GMT

The code comment checking policy currently checks all source code files that are being checked in based on a rather simple logic inside method CCCPTfsPolicy::IsVerifyableFileType. However, it would be desirable to *exclude* certain projects from checking. The reasoning is that class libraries are a good candidates for checking proper code commenting, whereas eg a quick-and-dirty VB Winforms frontend checked into the same team project doesn't need code comments at all. Things to be evaluated: is there a way in the checkin policy to find out which file belongs to which project? Or would we need to track this based on directories and mapped workspaces?

CREATED FEATURE: MSBuild Task for CCCP

ChristophWille — Sun, 21 Jan 2007 13:53:14 GMT

The MSBuild task will enable the following: * calculating the "comment coverage" * outputting a detailed list of methods, etc that don't have proper code comments * possible to run it as part of Team Build Comment coverage is already being tracked inside cccplib, the functionality hasn't been surfaced to far though. The output format of all three feature areas needs to be discussed, ideally it should be similar to what NUnit outputs.