The intent of this post is to save the next poor bastard that encounters this error, and spends hours googling (err…binging?) for it only to find out that it is a quick fix that has nothing to do with the error.
I love Ninject, and I love log4net. I tend to pull them in to any project that I’m working on. And Ninject provides great support through its Ninject.Extensions.Logging package for getting log4net loggers injected into your classes with very little work. But one thing always bugged me: you have to put an [Inject] attribute on every ILogger property that you want injected. I hate that, because it scatters Ninject all over your implementation classes, and as a general rule your classes should be agnostic toward whatever IoC container you happen to be using. So, I created the NinjectAutoLogging package to allow for automatically injecting ILogger properties without the need for the attribute.
A few days ago I went to start a new project using Entity Framework. Like every other relational database in the world, I knew I would need some “lookup value” style tables. Y’know, WidgetStatus, FrobbleType, that sort of thing. EF had never had a good mechanism for quickly defining and referencing these types of lookup tables, but now there is Enum support! I thought this would be perfect, but it turned out to be woefully inadequate. So, I realized that EF still needed a good answer to creating lookup tables. I did some searching, and couldn’t find any good solutions, so I wrote one.
I was sitting in my Operations Management class yesterday, and we were discussing statistical quality concepts such as the Six Sigma movement which the business world has been obsessed with for the last several years. As we were going through the concepts and the statistical calculations, I realized that the same calculations could demonstrate the value of some key ideas in the agile software movement, such as team size and the value of pair programming.
It brings me great joy that the title of this blog post is both technically accurate and evokes the type of comic-book language I use when trying to figure out MSBuild variable syntax. Every time I try to dive in and do something non-trivial with MSBuild, I get tripped up over PropertyGroups, ItemGroups, Item Metadata, and the differences in syntax between $(This), @(This), and %(This). I figure I’m probably not alone, so in this post I will try to help my future self, and everyone else that can’t keep this stuff straight.
A few days ago I installed VS 2012, and everything seemed fine. But today I went to work on an existing MVC 3 app, and I couldn’t get it to work. It turns out there are some fairly simple changes that you need to make in the csproj and web.config files for your MVC 3 project in order to get it to work again after installing VS 2012. Hopefully this post will save someone else the same headache that I went through.
If you have read other posts on this blog, you may realize that I am a fan of Silverlight. I thought (and still do think) that with that technology Microsoft really hit a sweet spot with simplicity, ease of deployment, usability, and developer productivity. This is especially true for those devs working on internal, line-of-business apps, of which there are quite a few. And internal LOB apps have been Microsoft’s bread and butter for devs tools for a long time with products like VB, WinForms, etc. If an organization of any significant size runs on top of Windows, then most likely it employs a team of developers working on these technologies.
But lately, with Microsoft’s shift in focus toward ASP.NET MVC, jQuery, HTML 5 and other cutting-edge web standards, the amount of things the average developer has to care about has exploded. Has this strategy alienated the Dark Matter Developers that have supported Microsoft for so long? And does Microsoft have the agility, expertise, and community support to compete in the world of “real” websites like Twitter and Google? Are they putting too much energy toward the 1% of top developers and ignoring the 99% that just want a simple dev stack that will be stable for 10 years?
Lately I’ve been playing with the new NuGet integration that is baked into TeamCity 7.X. It works great, and has almost all of the features that I was looking for. However, there still needs to be some thought put toward how you should configure your project for publishing packages. For example, do you want new packages generated and published every time a developer commits a change, or only on demand when a candidate build is vetted as “stable”? TeamCity gives you all of the Lego blocks you need to get the setup you want, but you still have to arrange those blocks in the way that makes sense for you and your team. In this post I’m going to describe the setup that I recommend for publishing NuGet packages with TeamCity.