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.
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!