.NET uses Type everywhere to represent type information.Not surprisingly Type is language-agnostic. In many cases it is useful to get the friendly (aka language-specific) name for a Type object. .NET does not provide this easily. There are several different approaches but none of them work really well if you want the name that would have been used in your favorite language. This post will discuss some of the options available and then provide a more general solution to the problem that doesn’t actually require much effort.
Auditing is generally important in most databases because it is important to know who changed data and when. How auditing data is stored depends upon the system requirements but in general the date/time and user who made a change is important. SQL Server already provides the infrastructure to identify the who and what. Setting up EF to provide this information is straightforward once you know how EF works. In this post I’ll illustrate a simple approach we’ve been using in web applications for over a year with no issues and very little effort.
In a recent series of articles I discussed how to create an environmental tranform template that could be run on each build. I also posted a series of articles on how to generate a template to generate a strongly typed class to back appsettings in a configuration file. Alas shortly thereafter VS2013 Preview was released and changes to VS have broken the code. This post will discuss the minor changes that need to be made to get everything to work.
Note: This is strictly my opinion and in no way should be conveyed as the opinion of anyone else.
Now that the Win 8.1 Preview is out I can give my personal opinion on it. First we should discuss some of the new features and then whether it is a mandatory upgrade or not. Note that I’m ignoring all the new features around corporate environments and Windows Store apps.
In the previous article we updated the build process to support environmental config transforms in projects and to have the transforms run on any build. In this article we are going to package up the implementation to make it very easy to add to any project. There are a couple of things we want to wrap up.
- Place the .targets file into a shared location
- Add an import into the current project to the .targets file
- Add environmental config transforms into the project
- Remove the default config transforms generated by Visual Studio
Configuration file transforms have been around for quite a while and most companies use them to generate different config files for each environment but Visual Studio does not really support the functionality most companies need.In this article I’m going to talk about why the existing Visual Studio implementation is flawed and how to fix it so that you can have true environmental transforms that are actually useful.
For purposes of this article we will assume a simple web application (although it applies to any application) that will be deployed to 2 different environments – test and production. We will also assume that developers debug the application on their local machine and therefore should not have to do any special tasks to debug the application locally. As such we’ll have a 3th, default, environment – debug.
In this final article in the series we’re finishing up the deployment projects started last time. When we’re complete we’ll have a set up projects that can be used to build and deploy T4 templates where needed. The projects will be able to support any number of templates so maintenance will be simple even as more templates are added. In the previous article we moved the core template functionality into a library that we can expand upon. We also set up an item template project to store the root T4 template that someone would use. In this article we’re going to create the project to store the nested templates (we’ll discuss why later) along with the Visual Studio Extension (vsix) file that will be used to install everything.
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.
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.
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