Use Publicize.exe to Create Private Accessors for Visual Studio 2012+

Preface

Starting with Visual Studio 2012, private accessors cannot be created any more by the IDE. The post Home-made Private Accessor for Visual Studio 2012+ presents an approach on how to create private accessors using the class Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject.

Axel Mayer noted in the MSDN forums post How to create private accessors in VS 2012 that one can use the command line tool publicize.exe to create private accessors too.

Usage Of Publicize.exe

The usage of publicize.exe is quite simple. Open a command prompt, or a “VS2013 x86 Native Tools Command Prompt” to have the search path already set up, and run publicize.

In case you do not have the path set up correctly, the tool can be found at %Program Files (x86)%\Microsoft Visual Studio 11.0\Common7\IDE for Visual Studio 2012 or %Program Files (x86)%\Microsoft Visual Studio 12.0\Common7\IDE for VS 2013. At least, the tool is located there for the Ultimate edition of Visual Studio. I can’t tell which other editions contain it. Just have a look.

For a complete reference please refer to Using Publicize to Create a Private Accessor.

The usage in short: publicize.exe [options] input-assembly

The created assembly needs to be referenced by the test project. Of course, the source assembly – the assembly containing the classes to be tested – has to be referenced by the test project too.

publicize.exe creates classes named NameOfTheSourceClass_Accessor. In case the class to be tested is called MyClass, the accessor is named MyClass_Accessor.

publicize did work well for .NET 4.0 and .NET 4.5 assemblies in my tests. It also covered async and static methods.

Limitations

The docs mention that publicize does not support delegates or events.

From my tests I can add another limitation: publicize does not support Windows Store app assemblies (or I was not able to use it correctly). Running it against such an assembly I received these error messages (and a few more of the same type):

Cannot resolve dependency to Windows Runtime type ‘Windows.UI.Xaml.Application’. When using the ReflectionOnly APIs, dependent Windows Runtime assemblies must be resolved on demand through the ReflectionOnlyNamespaceResolve event.

Cannot resolve dependency to assembly ‘System.Runtime, Version=4.0.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.

Maybe you can give a hint on how this can be resolved. If so, please add a comment below. Thanks!

Resumé

As long as I don’t need accessors for Windows Store app assemblies, the usage of publicize.exe is my preferred way to generate private accessors.

In case publicize.exe does not support the source assembly type, I will created the private accessor myself as described by Home-made Private Accessor for Visual Studio 2012+.

Links

Home-made Private Accessor for Visual Studio 2012+

How to create private accessors in VS 2012

publicize.exe documentation

Home-made Private Accessor for Visual Studio 2012+

Why Home-made?

Short answer: Starting with Visual Studio 2012, private accessors cannot be created any more by the IDE.

It seems that this does not bother too many people. The ‘Bring Back Private Accessor’ suggestion on UserVoice has not found any supporters right now.

Nevertheless, I still need access to private members of classes for testing purposes. And I do not want to declare them as internal because these members should not be (mis)used from within the same assembly.

Update 2013-11-09

Axel Mayer noted in the MSDN forums post How to create private accessors in VS 2012 that one can use the command line tool publicize.exe to create private accessors too. See Use Publicize.exe to Create Private Accessors for Visual Studio 2012+ for a detailed description.

The Goals

Just a few things:

  • Type safety
  • Protect from typos
  • Easy to handle when rename is required
  • Encapsulate / hide the use of PrivateObject

Use of PrivateObject

Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject is the base class to build up our own private accessor infrastructure. Well, infrastructure is such a big word. As you will see later, this infrastructure is really lightweight.

The direct use of PrivateObject has some disadvantages. You always have to use strings as parameters to invoke a method or get / set the value of a property. So there is a good chance the call of a method fails because I mistyped the method name. Some casting issues come up too. And using async / await in .NET 4.5, the direct use of PrivateObject.Invoke does not look really funny.

The direct use of PrivateObject looks like this

// Create an instance of the class to be tested.
ClassToBeTested instance = new ClassToBeTested ();

// Create a PrivateObject to access private methods of instance.
PrivateObject privateObject = new PrivateObject(instance);

// Create parameter values
object[] args = new object[] { "SomeValue" };

// Call the method to be tested via reflection, 
// and pass the parameter, and cast the result
int result = (int) privateObject.Invoke("PrivateMethod", args);

// Do some validation stuff

Create an Accessor Class

The first step to get away from this unpleasant and code inflating use of PrivateObject is to create an accessor class inside the unit test assembly.

This accessor class will hide the usage of PrivateObject. It gives type safety and helps to avoid typos on method- and property names. In case a member of the tested class is renamed, there is one single place to change in the test assembly. All other changes in the unit test can be done by Visual Studio renaming support.

A short version of the accessor to ClassToBeTested might look like this:

internal ClassToBeTestedAccessor
{
  private PrivateObject PrivateObject { get; set; }

  internal ClassToBeTestedAccessor()
  {
    PrivateObject = new PrivateObject(new ClassToBeTested());
  }

  internal int PrivateMethod
    (
    string parameter
    )
  {
    return ((int) PrivateObject
      .Invoke("PrivateMethod", new object[] { parameter }));
  }
}

And the test method using the accessor changes to this:

// Create an instance of the accessor.
ClassToBeTestedAccessor accessor = new ClassToBeTestedAccessor ();

// Call the method to be tested
int result = accessor.PrivateMethod("SomeValue");

// Do some validation stuff

Now the test method itself already looks the way I like it.

Make Accessor Reusable

Let’s assume there is the need for more than one accessor class in the test assembly. Then it might make sense to put some functionality into a base class for reuse purposes.

The base class should keep the instance of the tested class and the PrivateObject to access it. This means it have to be generic to get a type safe implementation.

This will be the starting point:

internal abstract class PrivateAccessorBase<T>
{
  private PrivateObject PrivateObject { get; set; }

  public T TestInstance 
    { get { return ((T)PrivateObject.Target); } }

  internal PrivateAccessorBase
      (
      T instance
      )
    {
      PrivateObject = new PrivateObject(instance);
    }
}

Please notice the public property TestInstance. This proporty gives access to the instance that is encapsulated by the private accessor. In case the unit test method needs to access public members of the tested class too, use this proporty.

What is common in my unit tests is to get or set the value of a property and to call a method. Therefore, the base class should offer the ability to do that.

Property Access

To get a property value, one might implement a method like this:

protected TReturnValue GetPropertyValue<TReturnValue>
  (
    string propertyName
  )
{
  return ((TReturnValue)PrivateObject
    .GetProperty(propertyName, null));
}

But this implementation still requires to pass the name of the property as a string. This can be avoided by using the call stack (in case you are using .NET 4.5 or higher, please have a look below to avoid StackFrame usage):

protected TReturnValue GetPropertyValue<TReturnValue>()
{
  // Need to remove the "get_" prefix from the caller's name
  string propertyName 
    = new StackFrame(1, true).GetMethod().Name
      .Replace("get_", String.Empty);

  return ((TReturnValue)PrivateObject
    .GetProperty(propertyName, null));
}

Setting a property value looks quite similar:

protected void SetPropertyValue
  (
  object value
  )
{
  // Need to remove the "set_" prefix from the caller's name
  string propertyName 
    = new StackFrame(1, true).GetMethod().Name
      .Replace("set_", String.Empty);

  PrivateObject.SetProperty(propertyName, value, new object[] { });
}

Having this base class, we can implement the ClassToBeTestedAccessor like this:

internal ClassToBeTestedAccessor
  : PrivateAccessorBase<ClassToBeTested>
{
  internal ClassToBeTestedAccessor ()
    : base(new ClassToBeTested())
  {
  }

  internal int PrivateProperty
  {
    get { return (GetPropertyValue<int>()); }
    set { SetPropertyValue(value); }
  }
}

The usage of the property by the test class does not differ from the usage of ‘normal’ properties:

// Create an instance of the accessor.
ClassToBeTestedAccessor accessor = new ClassToBeTestedAccessor ();

// Set the value
accessor.PrivateProperty = 231;

Debug.WriteLine("PrivateProperty: >{0}<", accessor.PrivateProperty); 

Method Access

Based on this, it is simple to implement the access of non-public methods in the accessor base class.

// Implemented by PrivateAccessorBase
protected TReturnValue Invoke<TReturnValue>
  (
   params object[] parameter
  )
{
  return ((TReturnValue)PrivateObject.Invoke(
    new StackFrame(1, true).GetMethod().Name, parameter));
}

The accessor class uses this method like this:

// Usage by ClassToBeTestedAccessor
internal int PrivateMethod
  (
  string parameter
  )
{
  return (Invoke(parameter));
}

Using the PrivateAccessorBase together with a derived accessor class, the typo danger is eliminated. We got type safety, the accessor implementation does not contain PrivateObject usage, and there is a single place to be changed when some property or method names of the tested class will change.

Preconditions

There is only one precondition: The properties and methods names of the accessor class have to match 100 percent with the corresponding members of the tested class!

Avoid Inlining

One thing really important when using the StackFrame is to make sure the caller's name will not change. How might this happen? When the JIT compiler thinks it should optimize the code by inlining methods.

This would be fatal when using the call stack to get the name of the original caller. As soon as a method is inlined, the call stack changes.

Sample: Assume ClassToBeTestedAccessor.PrivateMethod will be optimized, because it only contains the call to PrivateAccessorBase.Invoke. In this case, the name of the caller in PrivateAccessorBase.Invoke won't be 'PrivateMethod' any more, but the name of the method that called ClassToBeTestedAccessor.PrivateMethod. Using this name, let's assume it is 'TestPrivateMethod', as the method name parameter of PrivateObject.Invoke, the test will fail with an exception, telling the method 'TestPrivateMethod' was not found.

Even if unit tests normally run in debug mode (the 'Optimize code' option is not set in the project's build configuration), one should be aware of this. To make sure the JIT compiler does not inline a method, set the [MethodImpl(MethodImplOptions.NoInlining)] attribute. The sample solution shows how and where.

Changes in .NET 4.5

In case you can use .NET 4.5 or above, you don't have to care about inline optimization 🙂

.NET 4.5 introduced the class CallerMemberNameAttribute. Using this class, there is no need to worry about these things. The attribute is processed by the C# compiler when it produces the IL code. Optimization is done by the JIT compiler later on (see forum post CallerMemberNameAttribute and Inlining).

For the .NET 4.5 implementation, the usage of MethodImpl and StackFrame is obsolete. The PrivateAccessorBase changes to this:

// Implemented by PrivateAccessorBase
protected TReturnValue GetPropertyValue<TReturnValue>
  (
  [CallerMemberName] string callerName = null
  )
{
  return ((TReturnValue)PrivateObject.GetProperty(callerName, null));
}

protected void SetPropertyValue
  (
  object value,
  [CallerMemberName] string callerName = null
  )
{
  PrivateObject.SetProperty(callerName, value, new object[] { });
}

protected TReturnValue Invoke<TReturnValue>
  (
  [CallerMemberName] string callerName = null,
  params object[] parameter
  )
{
  return ((TReturnValue)PrivateObject.Invoke(callerName, parameter));
}

Please notice that even the removal of the 'get_' / 'set_' prefix is not required any more.

The ClassToBeTestedAccessor has to name the parameter passed to PrivateAccessorBase.Invoke to make sure the first parameter is not interpreted as the caller method name.

// Implemented by ClassToBeTestedAccessor
internal string ProtectedMethod
  (
  string parameterValue
  )
{
  // Need to name the parameter, 
  // otherwise the first parameter will be 
  // interpreted as caller's name.
  return (Invoke(parameter: parameterValue));
}

Test Static Member

To access static class members, no class instance or PrivateObject is required. The PrivateAccessorBase collects all properties and methods the type defines, using the static constrcutor.

// Implemented by PrivateAccessorBase
private static IEnumerable DeclaredProperties { get; set; }

private static IEnumerable DeclaredMethods { get; set; }
…
static PrivateAccessorBase()
{
  TypeInfo typeInfo = typeof(T).GetTypeInfo();

  PrivateAccessorBase<T>.DeclaredProperties 
    = typeInfo.DeclaredProperties;

  PrivateAccessorBase<T>.DeclaredMethods 
    = typeInfo.DeclaredMethods;
}

One have to search for the property / method having the matching name, and invoke it.

// Implemented by PrivateAccessorBase
protected static TReturnValue GetStaticPropertyValue<TReturnValue>
  (
  [CallerMemberName] string callerName = null
  )
{
  return ((TReturnValue)PrivateAccessorBase<T>
    .DeclaredProperties
      .Single(info => info.Name.Equals(callerName))
        .GetValue(null));
}

protected static void SetStaticPropertyValue
  (
  object value,
  [CallerMemberName] string callerName = null
  )
{
  PrivateAccessorBase<T>.DeclaredProperties
    .Single(info => info.Name.Equals(callerName))
      .SetValue(null, value);
}

protected static void InvokeStatic
  (
  [CallerMemberName] string callerName = null,
  params object[] parameter
  )
{
  PrivateAccessorBase<T>.DeclaredMethods
    .Single(info => info.Name.Equals(callerName))
      .Invoke(null, parameter);
}

Please note that this is the .NET 4.5 implementation. For .NET version < 4.5, please refer to the sample solution.

Test Async Methods

Having the above in place, and putting it together with the description of the post Unit-Testing of Private Async Methods with Visual Studio, it is easy to extend the base class to be ready for calling async methods.

// Implemented by PrivateAccessorBase
protected async Task<TReturnValue> InvokeAsync<TReturnValue>
  (
  [CallerMemberName] string callerName = null,
  params object[] parameter
  )
{
  TReturnValue returnValue 
    = await (Task<TReturnValue>)PrivateObject
      .Invoke(callerName, parameter);

  return (returnValue);
}

The derived class uses it like this:

// Implemented by ClassToBeTestedAccessor
internal async Task<double> PrivateMethodWithReturnValueAsync
  (
  int millisecondsDelay,
  string outputText
  )
{
  double returnValue 
    = await InvokeAsync<double>
      (parameter: new object[] { millisecondsDelay, outputText });

  return (returnValue);
}

And the testing class uses the accessor this way:

// Implemented by ClassToBeTestedTest
[TestMethod]
public async Task TestPrivateMethodWithReturnValueAsync()
{
  int millisecondsDelay = 300;
  string testValue = "method unit test";

  ClassToBeTestedAccessor accessor 
    = new ClassToBeTestedAccessor();

  double result 
    = await accessor
      .PrivateMethodWithReturnValueAsync(millisecondsDelay, testValue);

  // Do validation stuff
}

Not Complete

The intention of this post and the sample solution is to give you an idea on how to create a home-made private accessor, and what to take care of when doing so.

The intention is not to offer a complete substitute of Visual Studio's Private Accessor Creation feature.

Accordingly, not all possible unit test scenarios are covered. Please feel free to extend the code for your needs and share your solutions and ideas with us by adding comments describing it.

Conclusion

Having this accessor base class, the creation of private accessors should be quite easy. Of course, not as easy as clicking a menu item, but better than fiddling around with PrivateObject.

The code snippets in this post might look a little bit complex and / or confusing. In this case, try to focus on the test class and accessor. Forget about the PrivateAccessorBase.

I hope you agree that both the creation of the accessor and the usage by the test class will be very comfortable and straightforward, having PrivateAccessorBase in place.

The Sample Solution

The sample solution contains four projects:

  • ConsoleApplication contains the class to be tested, based on .NET 4.0.
  • ConsoleApplication.4.5 contains the class to be tested, based on .NET 4.5.
  • ConsoleApplication.Test contains the PrivateAccessorBase, the accessor class, and the unit test class for ConsoleApplication, based on .NET 4.0.
  • ConsoleApplication.Test.4.5 contains the PrivateAccessorBase, the accessor class, and the unit test class for ConsoleApplication.4.5, based on .NET 4.5.

The class that is tested is ClassWithNonPublicMembers, located in the ConsoleApplication… projects.

You need Visual Studio 2012 or higher to build the solution.

Here you can download the code.

Test Explorer Output

Links

Upgrading Unit Tests from Visual Studio 2010

'Bring Back Private Accessor' suggestion on UserVoice

Eric Gunnerson's Compendium: Why doesn't C# have an 'inline' keyword?

CallerMemberNameAttribute

Forum question CallerMemberNameAttribute and Inlining

MSDN forum post How to create private accessors in VS 2012

Use Publicize.exe to Create Private Accessors for Visual Studio 2012+

SCC Removal Tool for TFS / Visual Studio

Preface

Publishing sample code to the blog requires some manual tasks to remove all the source control configurations and files as well as the user specific files of Visual Studio.

After publishing a few code samples, having to do the same changes manually again and again, I thought it was time to create a tool doing this for me. Of course, taking the time I needed to build that tool, I could have published a few more code samples. But it is much more fun to write a tool than to do the same thing again and again 😉 And of course, having a tool makes sure I will not forget a step.

The primary intention is to disconnect the solution from source control. I don’t like samples downloaded from the internet where the first thing that happens is, that VS complains it cannot connect to the source control. Beside removing the SCC footprint, the tool also deletes all the output. I think the output is not needed when the source code is delivered.

This tool is created based on the usage of TFS 2012 und Visual Studio 2012. So maybe, when using older versions of VS or other version control systems, this tool might not remove all the SCC footprint.

SCC Files To Delete

TFS creates a .vssscc for each solution and a .vspscc file per project. The tool searches for these files in the working directory and its subdirectories and deletes them.

Disconnect From Source Control

The solution file .sln file contains some information about the source control system where the code is stored. All this is configured inside GlobalSection(TeamFoundationVersionControl). The whole section needs to be removed to disconnect the solution from source control.

The project file .csproj (suffix of C# projects) also contains some SCC footprint. Every line starting with >Scc needs to be removed too.

User Files To Delete

Visual Studio stores user-specific information related to the solution in .sou files. User-specific information related to the project are stored in .user files. The tool deletes all of these file types in the working directory and below.

Directories To Delete

By default, the output of a project is written to bin and obj directories, which are located below the project directory. All directories with these names are deleted. You can enter additional directory names in the “Remove Directories” field. I use this because I change the output for all configurations to “.\Output” by default.

And for those of you who create unit tests: the TestResults directories are included in the list of default directories too.

Configuration Abilities

The tool reads the default file types and directories to be deleted from the app.config. So in case you like to change these values, just edit the file. The tool also stores the values entered (working directory and additional directories to be removed) into the app.config.

The SCC footprint detection of the solution and project files is hard-coded. So in case you need some changes here, you have to change the code.

Maybe Incomplete

Yes, the tool might be not be complete. There are several reasons for this: C# is the preferred programming language in my company. So maybe some language-specific files or settings are not covered by the tool.

Also, we do create only a small subset of applications types, like WPF, Windows services, … So maybe SharePoint or Office projects look different. Again, if you need to cover these project types and the tool does not: you have the code, so change it.

Not To Be Forgotten

The software is provided “as is”, without warranty of any kind, expressed or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.

Be careful!

The source code can be found here.

SCC Remover Screenshot

Make Custom Class Item Templates for Windows Store Apps Visible in VS 2012

Make the Item Visible

One very helpful feature of Visual Studio is the ability to create custom item or project templates. I’m using this feature for years to get a pre-formatted C# class, containing several regions.

In VS 2012, one can set the directory where these custom item templates are located via “Tools / Options / Projects and Solutions” dialog. This folder contains several subfolders for some categories, i.e. JavaScript, Visual Basic, or Visual C#. These were the places where to put the appropriate custom item templates.

The first thing that has changed in VS 2012 (at least Update 3, can’t recall if this has changed before) compared to VS 2010 is that you have to create a “My Templates” folder below the corresponding one. Means, if I have a custom C# class item template, it has to be put into “C:\Users\nnn\Documents\Visual Studio 2012\Templates\ItemTemplates\Visual C#\My Templates” to be shown in the “My Templates” section of the “Add New Item” dialog.

But this did not work for all kinds of project types. At least, it does not work for Windows Store app projects. Even though the item template is located at the right place, it is not listed by the “Add New Item” dialog. Of course it is listed in a Windows console app project.

For whatever reason, the Windows Store app project requires an additional setting in the vstemplate file, which is part of the item template zip file. This setting is the element <TemplateID>Microsoft.CSharp.Class</TemplateID> inside the <TemplateData> section. Putting the updated vstemplate into the class item zip, the template is also listed in the “My Templates” section of the “Add New Item” dialog in Windows Store app projects. The TemplateID is not generated when exporting the template by VS.

You might notice too, that from the moment on when the TemplateID is added, the item template will be listed twice for other project types, i.e. Windows console application.

After making these changes, I had some issues with the item template cache (retrieving an error when selection one of the duplicates in the list). I just deleted the directory ItemTemplatesCache in “C:\Users\nnn\AppData\Roaming\Microsoft\VisualStudio\11.0”.

How to Create a Custom Item Template

In case you hadn’t created a custom item template yet, have a look at How to: Create Item Templates.

On my VS 2012 installation, the “Export Template…” menu item was not part of the File menu. So I had to add it using the “Tools / Customize” dialog. Switched to the “Commands” tab, selected “Menu bar”, “Add Command”, selected “File” from the categories, and already found the missing item.

Exporting the template, it will written to “C:\Users\nnn\Documents\Visual Studio 2012\My Exported Templates” by default. Selecting the “Automatically import the template into Visual Studio” option copies the file to the directory configured in the VS 2012 settings (see above). The default is “C:\Users\nnn\Documents\Visual Studio 2012\Templates\ItemTemplates”. You have to move it into the appropriate subdirectory yourself!

Links

I have to confess that I did not found out all of it by myself. Here are the links to the postings in MS forums where I found most of the informations:

  • Can’t see My Templates (VS 2012 Update 3)
  • Where to put Custom Item Templates for Windows Store Apps (XAML/C#) in VS2012 Update 3?
  • Visual Studio UI Toolbox disappeared

    I can’t recall if it was right after the initial installation, or if I hit any whatever key-combination to hide it, or closed it by mistake: The UI toolbox in my Visual Studio 2012 was not visible. First, I did not care because I didn’t needed it. But the point in time came when I needed it – and still it was not there. Neither a ‘Toolbox’ item in the View menu.

    I searched the internet, did a repair, did a toolbox rebuild, reset the window layout, and was close to un- and reinstall it. Then, after searching again, I found a posting for VS 2008 SP1. It says one can use the CTRL+ALT+X key to show the toolbox window. Fortunately, the key combination worked for VS 2012 too! The toolbox window was back again 🙂 This saved me several hours of non-productive installation time.

    Soon, I added the Toobox command to the ‘View / Other Windows’ menu to make sure I will not lose it again.

    And in case you need to rebuild the toolbox content, you can do this:

    1. Close Visual Studio;

    2. Open the “c:\Users\\AppData\Local\Microsoft\VisualStudio\11.0″ folder and remove all the .TBD files;

    3. Start regedit;

    4. Find the “HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\ToolboxControlsInstaller_AssemblyFoldersExCache” and “HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\ToolboxControlsInstallerCache” keys;

    5. Remove everything from these keys leaving them empty;

    6. Run Visual Studio again and wait until it recreates all items in the toolbox. This might be a lazy rebuild, started when you open a UI control in the editor.

    (found this list here: www.devexpress.com/Support/Center/Question/Details/K18560)

    Where Do SSDT SQL Scripts Connect To?

    In some software projects I used empty Visual Studio solutions to create some kind of database projects. I added SQL script files to the solutions to create all database objects, like tables, functions, stored procedures, views, constraints, and so forth. A batch file was used to run all these scripts against the database.

    One common part of these script files was a snippet of sample code to test the database object, e.g. a stored procedure or function, directly from inside Visual Studio. This snippet both documented the use and gave a quick way to test changes. Of course, this snippet was intended to be used only when connected to a local SQL instance to avoid damage in any other environment!

    Playing around with SQL Server Data Tools (SSDT) in VS 2012, I was looking for the ability to connect a function script to my existing local database. Under the menu item SQL / Transact SQL Edit / Connection there is the ability to connect to a database. To my surprise, I was not asked to which SQL instance or database I would like to connect to. At least, clicking the connect menu item seemed to do nothing at all.

    But running the script worked, and the result window told me that the function was created successfully. I was wondering where. Searching for a database selection option in the toolbars, as I know it from the SQL script files in VS 2010, failed. There is no such possibility. Was the function created in the master database? But which SQL Server instance was used?

    Well, Visual Studio showed me the answer to these questions all the time, but I did not noticed it.

    When you edit a function or a stored procedure script file of a SQL Server Database project – not a simple SQL Query file! – you will find these information in the properties window on the right (or wherever you have placed it). The properties window shows the connection name, logon name and so forth, and whether the connection is open or closed. You cannot change any entry. These properties are not available for table script files of the project, which can’t be connected to any database at all from within Visual Studio.

    But the properties window does not tell you the name of the database. Almost, it is the project’s name. But it doesn’t have to. The name can be found in the .sqlproj.user file, located in the project directory. Of course, you can edit this file to change the name.

    VS 2012 Recent Project List

    For whatever reason, the VS dev team decided to remove the Recent Projects from the File menu. Thankfully, they did not removed the command itself.

    The only thing one has to do is right-click the menu bar (or go to Tools / Customize), switch to the Commands tab page, select the File menu bar entry in the combo box, add a new menu named Recent &Projects, and move it wherever you like. Then select the newly created menu bar in the “Menu bar” combo box and add the command Recent Project List.

    Tired Of Office / Visual Studio Yelling!

    Have you already installed Office 2013 and / or Visual Studio 2012? And are you one of the “old-fashioned” internet guys who understand UPPERCASE as yelling? Then you might feel uncomfortable when you are looking at the headings of Office’s and Visual Studio’s ribbon bar.

    Thankfully, others were already tired of too, so there is an almost simple solution.

    For Office, go to www.dreamwalkerblog.com/blog/2012/12/fix-the-casing-on-new-microsoft-applications/, download the zip file, and run it. Maybe have a look at it prior to execution, it might contain a virus 😉 At the time of writing it didn’t. It was just copying a few files. This saves you from manually editing the ribbon bar, as described in www.askvg.com/how-to-get-rid-of-all-caps-tab-titles-in-microsoft-office-2013-ribbon/.

    To change Visual Studio, one has to set a registry key, as described in blogs.msdn.com/b/zainnab/archive/2012/06/14/turn-off-the-uppercase-menu-in-visual-studio-2012.aspx. The zip file mentioned above includes this too. But you should remove the registry settings you do not need. Maybe you have to open the command line as an administrator. On my machine, that part did not work, but it’s really easy to use regedit.

    And to see what the community thinks about this “feature”, see social.msdn.microsoft.com/Forums/eu/officedevpreview/thread/39b4b762-5ffa-4306-8c6a-7811d022334a.

    Update 2013-07-31: Configure VS 2013 (Preview)
    Found a good description at Stack Overflow. Just setting the registry key like done for VS2012 did not work on my machine. I installed the VSCommands.