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.
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.
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.
I am a big fan of using NuGet for managing dependencies between different .NET projects. Lately I’ve been focusing on using it for managing internal dependencies within an organization. Most organizations end up with some shared code that is used across multiple applications: logging, security, database access, common domain models, etc. A great way to handle this shared code is to publish it as an internal NuGet package, and then point all of the consuming applications at that package. Additionally, TeamCity can be used to ensure that new packages are created automatically whenever the shared code is updated, and those packages are instantly made available to consumers.
This setup works great, but it can be confusing as there are a lot of moving parts. One of the most confusing parts is the amount of different version / build numbers you end up juggling. This post explains how to configure everything so that the same version number is used in every piece across the entire process.
I started working for a new company a few weeks ago, and I have been spending a lot of time just getting used to the new portfolio and all of the new techniques and conventions in use there.
One of the things I wasn’t used to is the heavy use of stored procedures that act as custom getter methods within the DAL layer of the .NET applications. The DAL is code generated and the codegen templates automatically know to transform those sprocs into getters on the generated entity manager. So if I have a Customer table, and a sproc in the database called sp_Customer_SearchByName, the codegen process will automatically create a Customer entity, along with a CustomerManager that has a SearchByName method on it, which takes the same inputs as the sproc and returns a collection of Customers.
One of the things I’m looking at is whether Entity Framework makes sense for this portfolio, and I wasn’t sure how EF would handle this type of situation. After pleading ignorance, I was told the magic keyword that I needed: Function Imports!
NOTE: I have since solved this problem with a Ninject module that makes things much simpler. Check out this post for details.
This post describes a pattern I came up with for providing logging in an application is a very elegant way, with consumers of loggers able to use loggers that are injected via property injection. But, at test time if the logger is null, a NullReferenceException is prevented so that tests can be executed without having to provide a mocked logging interface.