Working with OpenAccess in Visual Studio 2010 Beta 2

If you’re like me, the end of the year represents a time when most other projects are starting to wind down and you finally have a chance to get back to testing some of those “fun” Microsoft betas. Visual Studio 2010 Beta 2 is probably at the top of the stack. Microsoft’s next major update to the flagship IDE is getting very close to RTM, so now is a great time to start checking-out the tool.

What you should be pleased to know is that almost all of Telerik’s developer tools already offer a lot of support for VS 2010- even as a beta! That truth extends to OpenAccess ORM. If you install the latest release of OpenAccess (2009.3.1119), you’ll discover that it effortlessly adds the expected design-time menus, wizards, and tools to VS 2010 that you need to work with your favorite Telerik ORM.

There is one “gotcha” in the current OpenAccess release, though, that you’ll want to handle if you decide to do .NET 3.5 or .NET 2.0 development in VS 2010.

Described in this forum thread, the problem relates to the version of the .NET framework that the OpenAccess assembly enhancer references when you build your project. With the current OpenAccess build, the enhancer will always reference the new .NET 4.0 framework assemblies by default, creating a problem that will likely break the builds of projects consuming your OpenAccess-enhanced assembly (I noticed this in my own projects when IntelliSense started reporting missing assembly references to assemblies I definitely had referenced).

Fortunately, the workaround is fairly easy. In the project properties for your class library containing persistent classes (the project that needs to be “enhanced” by OpenAccess), simply add this string (including quotes) to the “Post-build” actions on the project Build tab:

"c:\programs files\telerik\openaccess orm\sdk\venhance.exe" "-assembly:$(TargetPath)"

If you’ve installed OpenAccess to a non-default location (or if you’re on a 64-bit machine), make sure you update the path to “venhance.exe.” This will “manually” initiate the enhancing process and eliminate the unnecessary references to .NET 4. We also have to remember to “turn-off” the auto-enhancing that normally occurs during a build. To do that, simply:

Select your project, press F4 to open the properties window, and then set “Enhance” to “False.”

You’re now ready to use OpenAccess without issue in VS 2010 with .NET 3.5 and 2.0. The only other “tweak” you may need to make to your project is changing when the post-build event occurs. Depending on the type of project consuming OpenAccess-enhanced assemblies in Visual Studio, different behaviors will cause unexpected results. For instance, if you’re working on a web project, and you do the typical “Right-click > View in browser” on an ASP.NET page, Visual Studio will do a quick build of your solution. Depending on how the post-build event is configured for your OpenAccess project, this can lead to confusing “No enhanced assemblies found” run-time errors.

The “error proof” setup that I’ve decided to use is to set the post-build event to “Always.” It’s not the most efficient configuration (because the enhancer always runs on every build), but it has so far given me an environment where I don’t get any unexpected errors.

I hope this helps you remain productive as you start using OpenAccess in Visual Studio 2010 Beta 2. The OpenAccess Team is also, of course, working on addressing these issues for future builds (builds after 2009.3.1203), so eventually none of these steps will be required. This is an easy workaround in the mean time and it is good exposure to how the OpenAccess enhancing process works that should make you an even smarter (and more capable of troubleshooting problems) developer.