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.
These days most developers use NuGet to reference third-party dependencies like EntityFramework, Enterprise Library and NInject. A full discussion of NuGet is beyond this post. There are lots of articles on what it is, how to use it and how to package and publish to it so I’ll ignore all these things. But what about internal dependencies like shared libraries used by company applications? It turns out you can host your own private NuGet repository as well. Visual Studio is already set up to support this. The hard part is getting the repository set up. At my company we’ve been running a local NuGet repository for a year and it works great, for the most part. We have a company policy that all dependencies must be stored in NuGet. This pretty much eliminates versioning issues, sharing code across projects and storing binaries in source control. In this post I’m going to go over the steps to set up a private NuGet repository. Others have posted on this topic and there is some documentation available but unfortunately it is out of date.
Recently I was working on an MVC 4 application and I ran into a couple of issues with how property validation works with the default binder. I thought it was useful enough to share.
I’m finishing up my company’s second rewrite of an ASP.NET application to MVC and Razor. One of the things we learned along the way is that controllers and views are no more testable than forms and code behinds in ASP.NET. So we have been using the orchestrator pattern for newer code. I’d like to share our thought process on this approach.
UPDATE: My post triggered an e-mail exchange with Rowan Miller from the Entity Framework group. He wanted to explain and clarify some of my comments around EF. I’ve added them in the appropriate sections below. Thanks for the clarifications Rowan!
I understand the need for making some breaking changes to the framework as we transition to newer versions but one of the big selling features of .NET has been writing apps without having to worry too much about having the exact same version on end machines. Microsoft seems to be moving away from this goal with newer releases. .NET 4.5, as a framework, has a lot of nice, new features. But as the next version of the framework I think it fails on many levels. I’m fearful that this is becoming the new trend at Microsoft given the recent releases of .NET and other libraries.
I’ve recently been working on a project where I used Entity Framework for the data access. I’ve run into some challenges that don’t seem to be discussed much in the articles on how to properly use ORM. I’m curious if anyone else is having these challenges. While I’m using EF as my base I’m pretty sure that these challenges exist for other ORMs as well including NHibernate so I don’t believe the challenges to be caused by a specific ORM implementation but rather as a result of using ORMs in general.
We all know that the Settings infrastructure added to .NET a while back is the “correct” way to create strongly typed application settings in configuration files. The problem with this approach though is that the entries generated in the config file aren’t pretty. You have only limited control over the naming, there are lots of extra information to wade through and non-devs can easily get confused. The Appsettings that has existed since v1 is a simpler approach that most people are comfortable with. But you lose a lot of functionality by using AppSettings. The Settings infrastructure brings into play a Settings class with strongly typed properties for the settings and default values for settings that are missing. But sometimes that is overkill or simplicity is just too important.
Condusiv has recently released the next version of Diskeeper 12. I’ve been running it for a while now and I’m still satisfied with the way it optimizes my drives without eating up the resources. Traditionally I wipe my machine on a yearly basis because of all the extra stuff that gets installed and the slow down on the hard drives but since I’ve been using Diskeeper I’m averaging closer to 18 months now. The hard drive just isn’t running slow.
Now that VS 2012 RC is available I think it is time to reevaluate VS 2012 and see where it stands.
UPDATE: Great news!!! Microsoft has seen the error of their ways. They have formally announced that they will in fact release VS2012 Express for desktop apps (instead of just Metro)- http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx. This is a big win for students and hobbyists.
Well VS2012 is finally in RC mode. I have to say the UI is looking better but please, for the love of all that use VS every day, GET RID OF THE STUPID ALL CAPS MENUS!!!!! Who in the world is designing this stuff in Redmond? It’s like they never took UI design 101 classes. Everybody who has used a computer for more than 5 minutes knows where the menus are so why do they have to be highlighted? It couuld just be me but it seems like the management at MS are making more and more missteps with this release as we get closer. Now on to the really, really disasterous news for VS2012…