Question

I’ve generated unit tests on a private method using Visual Studio’s own “Create Unit Tests…” option.

Great, it works, but if I try to check my code in now I break the build because VS has created a private accessor class in AppData/Local/Temp that is required to build. If I try to put this file in my source tree, it won’t compile as the compiler says it “must define a body”. Really don’t understand this reflection lark…

This is the accessor class:

#region Assembly AgentConfiguration_Accessor.exe, v4.0.30319
// C:\Projects\AgentConfigurationTests\obj\Debug\AgentConfiguration_Accessor.exe
#endregion

using Agent.ConfigurationData;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;

namespace Agent.AgentConfiguration
{
    [Shadowing("Agent.AgentConfiguration.AgentConfigurationGui")]
    public class AgentConfigurationGui_Accessor : BaseShadow
    {
        protected static PrivateType m_privateType;

        [Shadowing(".ctor@0")]
        public AgentConfigurationGui_Accessor();
        public AgentConfigurationGui_Accessor(PrivateObject value);

        [Shadowing("_agentPaths")]
        public AgentPaths _agentPaths { get; }
        [Shadowing("_agentServiceName")]
        public static string _agentServiceName { get; set; }
        [Shadowing("UpdateStatus@1")]
        public void UpdateStatus(string statusMessage);
    }
}

Answer 1

After using the Private Accessors for some time, I had some troubles in getting the code to compile after some branching and merging with our Souce Code Versioning system.

I started researching on the topic and found an article in the Visual Studio Team Test blog. As far as I have understood it, you should not use the Private Accessor classes any more.

There is a blog article in the Generation of Private Accessors (Publicize) and Code Generation for Visual Studio 2010 that states that this feature is not further supported any more:

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:

• 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.
• 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.

Of course there are are suggestions about what you could do instead:

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.