locked
Visual Studio 11 Beta and TFS Check-in Policies RRS feed

  • Question

  • We're using a few check-in policies from the TFS Power Tools.  They work fine for us in VS 2010.  However, we receive policy errors when we attempt to check files in using VS 11.  We also have a custom check-in policy that we've developed.  Same story there - works fine in VS 2010 but fails in VS11.  Here are some examples of the error we receive when attempting to check-in:

    Internal error in Changeset Comments Policy.
    Error loading the Changeset Comments Policy policy (The policy assembly
    'Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ChangesetComments,
    Version=8.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not
    registered.). Installation instructions: To install this policy, follow the
    instructions in CheckForComments.cs.

    Internal error in Forbidden Patterns Policy.
    Error loading the Forbidden Patterns Policy policy (The policy assembly
    'Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ForbiddenPatternsPolicy,
    Version=8.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not
    registered.). Installation instructions:

    I've tried manually creating the registry keys that the policy installer creates, but using the VS 11 registry folder instead of 10.  (HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\Checkin Policies).  That didn't help.  Same error.  

    How do I get those check-in policies working?

    Thanks!


    Matt Varblow

    Thursday, March 1, 2012 6:39 PM

All replies

  • Check out the last post in this thread: 

    http://social.msdn.microsoft.com/Forums/eu/tfsversioncontrol/thread/24d0fb47-1270-405a-b0c5-b40db5b9ab6d 

    You'll need to follow a similar process to get 2010 policies to work in Dev 11


    My blog: blog.jessehouwing.nl

    Thursday, March 1, 2012 8:54 PM
  • Hi Jesse,

    That article is very helpful.  However, I don't think I'm getting far enough for the binding redirects to help.  The error is indicating that the policies aren't installed.  I think this usually means that it's not finding the registry entries. 

    I'm pretty sure I've got those registry entries installed correctly, though.  I assume that it works the same in VS11 as it did in VS8,9,10?  I exported my VS10 registry entries, edited the .reg file to replace Visual Studio\10.0 with Visual Studio\11.0, and then applied the .reg file.


    Matt Varblow

    Thursday, March 1, 2012 10:35 PM
  • Hi Matt, 

    Thanks for your post.

    I think the reason is that your version of TFS Power Tools(The latest version TFS Power Tools 2011 Decemberstill only supports VS 2010) only supports VS 2010, and we know that the Changeset Comments Policy and Forbidden Patterns Policy both defined in TFS Power Tools(please refer to this post), so I think this issue relate to that TFS Power Tools 2011 not support VS 11.

    In this scenario, I suggest you use that check-in policies in VS 2010.  


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us

    Friday, March 2, 2012 6:11 AM
    Moderator
  • Visual Studio doesn't see them as installed, because it looks for policies that inherit from a known class. That known class isn't the one from Visual Studio 2010, so that's where the binding redirects come into play. By explaining Visual Studio that these policies indeed inherit from the class it expects (through the redirect), it will be able to find them properly.

    My blog: blog.jessehouwing.nl

    Friday, March 2, 2012 9:09 AM
  • Hi Jesse,

    That makes sense.  Unfortunately, it doesn't seem to have worked, though.  I noticed that the devenv.exe.config already had the following entries (plus many additional binding redirects):

                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.Build.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.Common" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.VersionControl.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.VersionControl.Common" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>

    But, when I drill through the references in the power tools policy assemblies it looks like there are several additional entries that I'll need to cover references from references, etc.  I added the following:

       <dependentAssembly>
         <assemblyIdentity name="Microsoft.TeamFoundation.WorkItemTracking.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
         <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
        </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.VersionControl.Common.Integration" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.Common.Library" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.WorkItemTracking.Proxy" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.WorkItemTracking.Client.Cache" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.WorkItemTracking.Client.RuleEngine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.WorkItemTracking.Client.Provision" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.WorkItemTracking.Client.QueryLanguage" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="10.0.0.0-99.9.0.0" newVersion="11.0.0.0"/>
                </dependentAssembly>

                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ChangesetComments" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="8.1.0.0-9.9.0.0" newVersion="10.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.PowerTools.CheckinPolicies.CustomPathPolicy" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="8.1.0.0-9.9.0.0" newVersion="10.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ForbiddenPatterns" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="8.1.0.0-9.9.0.0" newVersion="10.0.0.0"/>
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Microsoft.TeamFoundation.PowerTools.CheckinPolicies.WorkItemQueryPolicy" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="8.1.0.0-9.9.0.0" newVersion="10.0.0.0"/>
                </dependentAssembly>

    But I still get the same errors.


    Matt Varblow

    Friday, March 2, 2012 2:21 PM
  • And you did register them in the registry in the new Dev11 location as well?

    My blog: blog.jessehouwing.nl

    Friday, March 2, 2012 2:23 PM
  • Hi John,

    Sounds like you're saying that it just won't work.  That would imply that check-in policies can only work with a single version of Visual Studio, which means that a given organization must have all their developers running on the same version of Visual Studio. 

    That's just not practical.  We would have to wait on the VS11 upgrade until all Microsoft tools built on VS have released a version that runs on VS11, e.g. SQL Server BI, BizTalk.  And all our developers would have to upgrade at the same time.

    I do wonder why these check-in policies haven't been rolled into the Visual Studio application yet.  Why are they still add-ons?  But my more immediate question is still - how do I make this work?  I need to be able to check files in and out from both VS10 and VS11.  It seems reasonable to expect that I should be able to do that without having to ignore policy failures on every checkin.


    Matt Varblow


    • Edited by mvarblow Friday, March 2, 2012 2:30 PM
    Friday, March 2, 2012 2:28 PM
  • Yes, they're registered under the VS 11 checkin policies registry key:


    Matt Varblow

    Friday, March 2, 2012 2:33 PM
  • Checkin policies, FxCop/CodeAnalysis rules, they've always been version specific and they don't play nice together. This has been a problem since the first version. It should be possible though. I haven't tried it myself with the Dev11 policies, but we've gotten it to work with the 2008/2010 versions before.

    You could try decompiling them (or just grab the source), re-applying the references to point to the Dev11 assemblies and compile. If that still works without code changes, the binding redirects should just work. Also make sure you're using the proper redirects, so that you're pointing either to the lowerst common denominator or to the latest version.

    I'm also not sure (as in I haven't tested yet) whether the new policies are built against .NET 4 or 3.5. This might be a bigger issue :(...


    My blog: blog.jessehouwing.nl

    Friday, March 2, 2012 2:33 PM
  • Hi Jesse,

    It looks like the checkin policies were built against .NET 4.  Seems like that's a good thing?

    I really appreciate your help.


    Matt Varblow

    Friday, March 2, 2012 2:37 PM
  • Looks like they're indeed both using .NET 4.0 x86 as the platform, in that case chances are high that redirections should work. I might try to get this to work this weekend and write a blog about it... Depending on time though :/...


    My blog: blog.jessehouwing.nl

    Friday, March 2, 2012 3:37 PM
  • A little more information:

    I enabled logging for assembly binding (using the Fusion Log Viewer).  I didn't see any errors related to the power tool assemblies.  In fact, I didn't see any evidence that it tried to load them at all.  So, I searched the registry to see if I was missing something.  I searched for "StanPolicy" since it comes pre-installed with both VS 10 and VS 11.  It turns out that the TeamFoundation\SourceControl\Checkin Policy hierarchy also appears in the HKEY_USERS hive. 

    I tried adding the registry entries for the power tools under the user folders.  Now the fusion log shows that it loaded the power tool checkin policy assemblies.  However, Visual Studio 11 still gives the same errors.


    Matt Varblow


    • Edited by mvarblow Friday, March 2, 2012 4:43 PM
    Friday, March 2, 2012 4:41 PM
  • Got the ChangeSet policy to work (was the easiest one, it has only one reference), the others should be doable as well, but I'll need more time to fidget with the references.

    My blog: blog.jessehouwing.nl

    Monday, March 5, 2012 2:24 PM
  • We were using the old TFPT 2005 policies (we have some branches in this team project that still use VS 2005, VS 2008).  I went into the Source Control settings for the team project and removed all the policies and then re-added them (on my machine which is running TFPT 2010).  This reconfigured TFS to use the TFPT 2010 instead of 2005.  Now, most of the policies work out of the box without any registry or config file hacking.  The only one that didn't work for me (that I tried) was the Custom Path policy.


    Matt Varblow

    Monday, March 5, 2012 3:21 PM
  • We were using the old TFPT 2005 policies (we have some branches in this team project that still use VS 2005, VS 2008).  I went into the Source Control settings for the team project and removed all the policies and then re-added them (on my machine which is running TFPT 2010).  This reconfigured TFS to use the TFPT 2010 instead of 2005.  Now, most of the policies work out of the box without any registry or config file hacking.  The only one that didn't work for me (that I tried) was the Custom Path policy.


    Matt Varblow


    Actually, only one worked out of the box without any config file hacking - the Changeset Comments policy.  Both the Forbidden Patterns and Custom Path policies did not work out of the box.  With the binding redirects (see my earlier post) the Forbidden Patterns policy did work, but not the Custom Path policy.

    Matt Varblow

    Monday, March 5, 2012 7:05 PM
  • Ok, tested with the TFS Power Tools December 2011 (so with the Visual Studio 2010 policies) in Windows 7 with both Dev11 and VS2010 installed. This successfully loads all check-in policies. I drilled down to all required dependencies using Reflector.NET and added a redirect for every assembly I was able to find.

    Registry settings

    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\Checkin Policies]
    "Microsoft.TeamFoundation.PowerTools.CheckinPolicies.WorkItemQueryPolicy"="C:\\Program Files (x86)\\Microsoft Team Foundation Server 2010 Power Tools\\Check-in Policy Pack\\Microsoft.TeamFoundation.PowerTools.CheckinPolicies.WorkItemQueryPolicy.dll"
    "Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ChangesetComments"="C:\\Program Files (x86)\\Microsoft Team Foundation Server 2010 Power Tools\\Check-in Policy Pack\\Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ChangesetComments.dll"
    "Microsoft.TeamFoundation.PowerTools.CheckinPolicies.CustomPathPolicy"="C:\\Program Files (x86)\\Microsoft Team Foundation Server 2010 Power Tools\\Check-in Policy Pack\\Microsoft.TeamFoundation.PowerTools.CheckinPolicies.CustomPathPolicy.dll"
    "Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ForbiddenPatternsPolicy"="C:\\Program Files (x86)\\Microsoft Team Foundation Server 2010 Power Tools\\Check-in Policy Pack\\Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ForbiddenPatternsPolicy.dll"
    
    [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0_Config\TeamFoundation\SourceControl\Checkin Policies]
    "Microsoft.TeamFoundation.PowerTools.CheckinPolicies.WorkItemQueryPolicy"="C:\\Program Files (x86)\\Microsoft Team Foundation Server 2010 Power Tools\\Check-in Policy Pack\\Microsoft.TeamFoundation.PowerTools.CheckinPolicies.WorkItemQueryPolicy.dll"
    "Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ChangesetComments"="C:\\Program Files (x86)\\Microsoft Team Foundation Server 2010 Power Tools\\Check-in Policy Pack\\Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ChangesetComments.dll"
    "Microsoft.TeamFoundation.PowerTools.CheckinPolicies.CustomPathPolicy"="C:\\Program Files (x86)\\Microsoft Team Foundation Server 2010 Power Tools\\Check-in Policy Pack\\Microsoft.TeamFoundation.PowerTools.CheckinPolicies.CustomPathPolicy.dll"
    "Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ForbiddenPatternsPolicy"="C:\\Program Files (x86)\\Microsoft Team Foundation Server 2010 Power Tools\\Check-in Policy Pack\\Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ForbiddenPatternsPolicy.dll"
    
    

    devenv.exe.config

    <!-- Added for Checkin policies -->
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.VersionControl.Client" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.Client" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.WorkItemTracking.Client" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.VersionControl.Common.Integration" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.VersionControl.Common" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.Common" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.Common.Library" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.WorkItemTracking.Client.QueryLanguage" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.WorkItemTracking.Proxy" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.Build.Controls" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>
          <dependentassembly>
            <assemblyidentity culture="neutral" name="Microsoft.TeamFoundation.VersionControl.Controls" publickeytoken="b03f5f7f11d50a3a">
            <bindingredirect newversion="11.0.0.0" oldversion="8.0.0.0-99.9.0.0">
          </bindingredirect></assemblyidentity></dependentassembly>

    My blog: blog.jessehouwing.nl

    Monday, March 5, 2012 8:49 PM
  • Actually, only one worked out of the box without any config file hacking - the Changeset Comments policy.  Both the Forbidden Patterns and Custom Path policies did not work out of the box.  With the binding redirects (see my earlier post) the Forbidden Patterns policy did work, but not the Custom Path policy.


    Matt Varblow

    The changeset comments policy was rolled into the product -- it's no longer part of the power tools. We've also done some additional work to make the in-box VS 2010 and VS 11 check-in policies play nicely with each other (you should be able to set them up with either client and have them work with either client). We should do this same compatibility work to the rest of the power tools check-in policies before we ship the final version. I'll file a work item to make sure this happens -- but I'm not sure it made it in for the Beta version of the VS 11 power tools. (I don't think the Beta power tools are out just yet -- but they're almost done.)

    Wednesday, March 7, 2012 12:50 AM
  • This did not work with VS 2012 RC.
    Monday, June 4, 2012 9:38 PM
  • hrusi,

    which policy did you try?


    My blog: blog.jessehouwing.nl

    Monday, June 4, 2012 9:41 PM
  • It didn't work for me also with 2012 RC
    Wednesday, August 1, 2012 4:13 AM
  • As far as I know, check-in policy compatibility is working well for the RTM version of Visual Studio 2012.

    Thanks,
    P. Kelley

    Wednesday, August 1, 2012 10:43 AM
  • Today i tested check-in policy compatibility with new VS2012 RTM. There is only partial compatibility.

    The policies CustomPathPolicy and ForbiddenPatternsPolicy still not working :(

    When i check-in from VS2012 into TFS 2010 get the error:

    Internal error in Custom Path Policy. Error loading the Custom Path Policy policy (The policy assembly 'Microsoft.TeamFoundation.PowerTools.CheckinPolicies.CustomPathPolicy, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not registered.). Installation instructions: Please contact your administrator

    Internal error in Forbidden Patterns Policy. Error loading the Forbidden Patterns Policy policy (The policy assembly 'Microsoft.TeamFoundation.PowerTools.CheckinPolicies.ForbiddenPatternsPolicy, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not registered.). Installation instructions:  Please contact your administrator.

    Visual Studio version is 11.0.50727.1 RTMREL


    Alexander

    Wednesday, August 15, 2012 8:45 PM
  • Alexander,

    Those two policies are part of the power tools, so they won't work until you install the VS 2012 power tools.

    But right now, the only 2012 power tools that are available are from the Beta release. The final RTM release of the power tools will be in mid-September. We have tested the compatibility of both of these check-in policies with the RTM power tools and they do work. I have not tried Beta, but I would not be surprised if there is a problem.

    Thanks for your patience.

    Thanks,
    P. Kelley

    Monday, August 20, 2012 1:09 PM