Generation of Private Accessors (Publicize) and Code Generation for Visual Studio 2010

We are letting you know of a few things that are happening in Visual Studio 2010 in regards to generation of Private Accesors and Code Generation. 

What is Publicize in Visual Studio testing?

Publicize is the ability to take internal application programming interfaces (API) and create public counterpart API that you can call in your tests, which would in turn, call into the internal APIs of your product.  This comes in the form of a stand alone executable, or can be seen when using code generation to create test method stubs of internal or private APIs.

What is Code Generation in Visual Studio testing?

Code Generation allows users to create test stubs and generates a little code snippet inside that stub.  This feature can be used in conjunction with Publicize to create test method stubs from internal APIs.

What is happening in Visual Studio 2010?

We have stopped working on these features for Visual Studio 2010 and may remove them from the product in following releases.  This is due to the following reasons:

1. Lack of resources and time: The focus for this release has been to improve the experience for manual testers, so the priority for the code generation and publicize features has been lowered.  There have also been other issues with the publicize functionality that we utilize that have not been addressed.
2. New features by Language teams:  As the language teams have made modifications to their project types and languages, we have been unable to respond to the changes they have made and have not been able to work with the new features they have introduced.

What is available for me then?

For those who wish to continue testing internal APIs, you have three options:

1. Use the Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject class to assist in accessing internal and private APIs in your code.  This is found in the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll assembly.
2. Create a reflection framework that would be able to reflect off your code to access internal or private APIs.
3. If the code you are trying to access is internal, you may be able to access your APIs using the InternalsVisibleToAttribute so your test code can have access to the internal APIs.

However, there is not any good replacement for Code Generation for the new features added by the lanugage teams.  You may create the TestMethod stubs and then remove the internal code.  You only need to keep the stub itself.

Will it be added back in or fixed in future releases?

At the moment, there are no plans to do this.  It may change based on priority and focus. Feedback welcome about this content or other items you would like us to consider for future releases.

Thanks

Bruce Taimana
Program Manager

• Anonymous
  March 09, 2010
  Is this still the case now that the RC is out?  I see that the option is still availible when right clicking on a private member, however does not seem to be working.  If this functionality is not going to be availible than why keep the menu item for Create Private Accessor in VS2010 for the RC. Thanks Ryan

• Anonymous
  March 30, 2010
  Correct.  We have not removed it from VS2010.  However, we have not made steps to fix core issues in these features.  In future (post Visual Studio 2010) these may be removed.

• Anonymous
  May 24, 2010
  The comment has been removed

• Anonymous
  June 02, 2010
  just info- in final vs 2010 release there is both included - the bug and the feature to generate private accessors. I guess in microsoft only Scott Gufrie knows what is and why unit testing (sometimes it looks that testing at all) is needed. quite disappointing... also what i noticed, that release of vs 2010 crashes at least time per day, but that's possible to live with. sometimes disabling wpf font caching service helps...

• Anonymous
  September 30, 2010
  This is apparently the root cause of a bug in VS2010 C# Unit Test generation.  I have a project with public interfaces (no private accessors) that uses covariant (<out T>) generic types. When VS2010 creates unit tests for this assembly, it apparently generates private accessors as part of its unit test wizard.  This causes the following type of error with every compile of either the original project or the unit test project: "Could not load type 'MultiTree.ITreeNode_Impl`1' from assembly 'MultiTree_Accessor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' because it declares a covariant or contravariant type parameter and is not an interface or delegate. MultiTree Unit Tests" Because every subsequent build gets this error, not only are these unit tests are totally useless, no other unit tests nor builds of the project under test can be successfully built.  See the post at social.msdn.microsoft.com/.../0bad3473-787c-4a8d-9b11-6c345bde780c for further discussion. Again, this is nothing that "I" created, but code generated by Visual Studio 2010 when creating unit tests using the Unit Test wizard, from a project that otherwise builds and runs without error or problem.  Either Visual Studio should be fixed to stop generating code that uses (broken) private accessors, or the issues with private accessors should be fixed.  (Since auto-generating unit tests of code that uses co- and contravariance seems to require them, I vote for the latter.)

• Anonymous
  August 29, 2011
  The comment has been removed

• Anonymous
  September 28, 2011
  Looking forward to good test coverage of my MVC3 controllers but removing tooling support  in VS2010 for testing private methods is now an impediment.   Why is this not treated as an important issue?  Surely testing is a major supposed benefit of ASP.NET MVC3?

• Anonymous
  January 02, 2012
  What about the BuildShadowTask problem?  I have been redirected to this page from connect.microsoft.com/.../buildshadowtask-nullreferenceexception, however, a clear workaround has not bee posted? Thanks

• Anonymous
  May 06, 2013
  improve the experience for manual testers? why not improve the experience for all people who want to test their code and just fix it.

• Anonymous
  January 10, 2016
  Make your methods internal: msdn.microsoft.com/.../system.runtime.compilerservices.internalsvisibletoattribute(v=vs.90).aspx