Using T4 to Create an AppSettings Wrapper, Part 6

In this (almost) final post in the series on creating an AppSettings wrapper in T4 we’re going to package all the work we’ve done into an easily deployable and reusable package that we can extend to include other templates.  We’ll also make sure that adding the template to a project is as easy as Add New Item.

Here’s the list of things we’ll accomplish

  • Create a custom base class and move all the shared template functionality to it.
  • Create a VS extension (VSIX) to install the parts of our template.
  • Install the shared template components into a centralized directory so projects only need to include the core template.
Read More

Using T4 to Create an AppSettings Wrapper

Update 28 Aug 2016: Refer to this link for updated code supporting Visual Studio 2015.

This is the table of contents for the series on using T4 to create an AppSettings wrapper for use in any code.

  1. Creating a static T4 Template for AppSettings
  2. Creating a dynamic T4 Template for AppSettings
  3. Reading Settings from the Configuration File
  4. Separating Customizable Parts from Static Parts
  5. >Customizing the Template
  6. Creating a Deployment Package (Part 1)
  7. Creating a Deployment Package (Part 2)

Using T4 to Create an AppSettings Wrapper, Part 5

In the last article we broke out the template into 2 separate template files: main and nested. A developer adds the main template to their project but it includes the nested template where the actual work is done. In this article we’re going to update the included template to allow a developer to alter the generated code without having to touch the nested template.

In the original article we listed 6 requirements for the template. At this point we have met half of them. By adding customization we will meet the final three. They are:

  • Exclude some settings
  • Change the type of a setting
  • Use the configuration file of a different project
Read More

NuGet with Active Directory Support

In a previous article I discussed how to host a private NuGet repository.If you aren’t familiar with NuGet then please refer to that article. If you’re hosting a private gallery then chances are you’re on a network (probably an Active Directory one). One downside to hosting a private NuGet gallery is that it is tied to Forms authentication. For a public repository this makes sense but for a private one it would be better to have NuGet use Windows authentication. This article will discuss the changes that have to be made to the NuGet source to support Windows authentication. The changes are scattered but minor.

Read More

Using T4 to Create an AppSettings Wrapper, Part 4

In the previous article we finished the basic appsettings template that allowed us to generate a strongly typed class from the settings in a configuration file. We now want to expand the template to allow it to be customized depending upon the needs of the project, a later article. Before we get there though it is time to refactor the code to make it more reusable and easier to maintain. That is the focus of this article.

Read More

Using T4 to Create an AppSettings Wrapper, Part 3

In the previous article we expanded the template to dynamically set the type and namespace names based upon the project the template is used in.Now we are going to turn our focus to generating properties for each of the settings in the configuration file. For this we’ll be adding more code to the class block to open and read the settings from the project’s configuration file (which we’ll have to write code to retrieve). We’ll also have to decide how to convert string values to typed equivalents.

Read More

Using T4 to Create an AppSettings Wrapper, Part 2

In the first article in this series we created a basic, static T4 template.The template allowed us to replace standard boilerplate code for reading an app setting

string setting = ConfigurationManager.AppSettings["someSetting"];

with strongly typed property references like this

var myIntSetting = AppSettings.Default.IntValue;
var myDoubleSetting = AppSettings.Default.DoubleValue;

Here’s a summary of the requirements from the first article (slightly reordered).

  1. All settings defined in the project’s config file should be exposed, by default, as a public property that can be read. I’m not interested in writing to them.
  2. Based upon the default value (in the config file) each setting should be strongly typed (int, double, bool, string).
  3. The configuration file cannot be cluttered with setting-generation stuff. This was the whole issue with the Settings designer in .NET.
  4. Sometimes the project containing the config file is different than the project where the settings are needed (ex. WCF service hosts) so it should be possible to reference a config file in another project.
  5. Some settings are used by the infrastructure (such as ASP.NET) so they should be excluded.
  6. Some settings may need to be of a specific type that would be difficult to specify in the value (ex. a long instead of an int).

In this article we’re going to convert the static template to a dynamic template and begin working on requirements 1-3. From last time here are the areas of the template that need to be made more dynamic.

  1. The namespace of the type
  2. The name of the type, including pretty formatting
  3. Each public property name and type
Read More

Using T4 to Create an AppSettings Wrapper, Part 1

AppSettings are settings stored in your configuration file under the <appSettings> element. Almost every application has them. Each setting consists of a name and value. To access such a setting in code you need only do this.

string setting = ConfigurationManager.AppSettings["someSetting"];

There are a couple of problems with this approach.

  • Quite a bit of boilerplate code to access a setting given what it is actually doing
  • The setting name is hard coded and must match the config file
  • The returned value is a string so if you need a different type then you’ll need to convert it

In .NET v2.0 Microsoft added the Settings class to work around these issues. It allows you to create a setting with a type and value and the designer will generate a type to back it where each property matches the setting. This seems great but never really took off. Not even Microsoft uses it in their own framework. Part of the problem is that the config entries it generates are overly complex storing things like type information, default values and other things. Needless to say appSettings continue to be popular anyway. Fortunately we can get the simplicity of appSettings with the power of the newer Settings class all via T4.

In this series of posts I’m going to walk through the process of generating such a template including the ability to add some more advanced functionality. A full discussion of T4 is beyond the scope of a blog so refer to the following links for more information.

Read More

MVP of the Year and Connect

I recently found out that I was one of the MVPs of the year for our group. Wow what an honor!! Given the caliber of MVPs one cannot help but be humbled by this. Unfortunately other obligations prevent me from attending the ceremony to receive the award. I found out later that one of the reasons was that I was supposedly the top bug reporter on VS 2012 for US dev MVPs. I reported 27 issues and 13 were actually resolved. This got me to thinking about Connect and how Microsoft has historically used it.

Historically when an issue was reported someone at Microsoft would try to replicate the issue. If they could then they would escalate it to the team and you’d receive some feedback. At that point the issue would either be fixed or, more likely, closed without reason. More recently Microsoft has started to close items with short descriptions like ‘by design’ or ‘won’t fix’. The one that drives me mad though is ‘we have to evaluate the priority of each item reported against our schedule and this issue is not sufficiently important. We will review it in the future’. Closed. The problem is that I’m not convinced they every do “review it in the future”. Even worse is that once an item is closed you cannot do anything with it anymore.

If, as happened recently to me, the folks at MS failed to grasp the issue you were reporting and closed the item then there is no way to tell them they messed up. Recently I reported an issue to Microsoft about the behavior of inline tasks for MSBuild (https://connect.microsoft.com/VisualStudio/feedback/details/768289/msbuild-path-used-for-inline-task-reference-is-not-honored). The issue is that an inline task can reference an assembly using a path. At compile time this is fine but at runtime the assembly path is not honored so unless you copy the assembly to the same location as the task then it will fail to the find the assembly. Now I understand the reasoning behind why it would fail. I also know that I’m not the only one who has seen this issue. It has been reported on multiple blogs over the years.

Somehow the folks looking at the issue got caught up with what the sample code was trying to do rather than what the actual bug was and reported that I should be using some built in task instead. How does that in any way relate to my problem? I don’t know but the item was closed anyway. Without starting a new item I cannot recover this closed item. Sure I left a follow up comment about it but the item is still closed, the bug still exists and I doubt it will ever get resolved. And I’d like to think that as a contributor to the community that my items get a least a little more attention than the general user but it wouldn’t appear so in Connect. If MS really wants us to report bugs and Connect is the tool to do so then the entire system needs to evolve into a more full featured issue tracking system where we can alert MS to issues that may have been closed incorrectly. Even more important issues that “may be resolved in a future release” shouldn’t be closed but deferred so we know that at least they are under consideration. Right now Closed means it’s fixed, it’s by design, it cannot be repro or it ain’t going to be fixed.

Historically MS has taken some flax from the community about the uselessness of Connect. With VS2012 they seem to have upped their game and started taking feedback more seriously but there is still much work to be done. There has to be more insight into where an item is in the process, policies for getting items reevaluated and a better system for identifying items that are closed or deferred. Perhaps the User Voice site will take over bugs as well. Right now it is more for suggestions. Time will tell. Having 50% of my reported items resolved indicates that Connect is starting to work, at least for me, but it has to work for everybody or else it isn’t going to be used.

Our industry is plagued by large egos. I try to keep mine in check (except around a few people who I know will take me for who I am, not what I’ve done). Where I work we have a motto “If you’re truly good you don’t have to say anything”. What that means is that bragging about being an MVP, writing a book, publishing a popular framework or whatever else gets you nowhere. If you’re truly good your works will speak for themselves. As such I will quietly place my plaque next to my MVP awards and move on. But recently one of our team members won both the Chili Cookoff contest and the Employee of the Year award in the span of two weeks. They proudly carried their awards the next few days to all their meetings. Maybe, just maybe, I’ll carry mine to a couple of meetings. If you’re truly good you don’t have to say anything but awards don’t talk do they :}

Hosting a Private Visual Studio Gallery

Visual Studio extensions are really popular these days. Not surprisingly Visual Studio has a very active extensions gallery. But unfortunately the gallery is public so if you develop some extensions for your personal use, or for your company, then you cannot use the public gallery. Fortunately though VS supports the concept of a private gallery. A private gallery is nothing more than an extension gallery that is not accessible to the world. It is discussed on MSDN so refer to there for more information about the what’s and why’s. Unfortunately the documentation is a little vague and setting one up is not trivial. I’m going to discuss the steps needed to get a private gallery up and running.

Read More