My ManuSoft manifest manifesto

With the advent of Visual Studio 2005 and automatically generated manifest files, the topic of when and how to use manifest files comes up occasionally. Since a default ObjectARX wizard generated project in Visual Studio 2005 generates an embedded manifest by default, most people don’t even think about it. Of course that was the whole idea — the manifest would ensure that the correct dependent DLLs get loaded, and voila, no *need* to think about it. One of my programming axioms applies in this case: TANSTAAFL.

The problem is that ObjectARX applications are not in charge. AutoCAD is in charge, and it will decide which VC runtime and MFC runtime DLLs to load. If your ObjectARX application loads a different VC or MFC runtime than the ones AutoCAD is using, you’ll encounter big problems. I’ve always advised disabling the manifest completely (see my ObjectARX Tips page) to avoid such a possibility. Unfortunately, there’s a catch.

The problem is that linking to the ATL80.DLL file isn’t possible by just disabling the manifest and doing nothing more. ATL is now a side-by-side (SxS) assembly, and it no longer lives on the Windows support path, so a standard un-manifested DLL won’t be able to find it. The preferred solution is to link statically to ATL (see Configuration -> General -> ‘Use of ATL’ in VS 2005 project properties) and avoid the problem altogether. If you only have one module that uses ATL, this is always the best solution.

The less desirable solution is to add a *manually-created* manifest that specifies the desired ATL SxS assembly, but ignores the VC and MFC runtime DLLs. You’ll still need to decide whether to make ATL shared or private, and in either case you *must* distribute ATL with your application to ensure that it is available when your application is deployed. You can cheat, and let VS generate your manifest file (instruct it to *not* embed the file), then just edit the resulting .manifest file to remove references to the VC and MFC assemblies. For example, here’s one that I generated (you’ll need to generate your own to ensure that the manifest matches the version you are redistributing):

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<assembly xmlns=”urn:schemas-microsoft-com:asm.v1″ manifestversion=”1.0″>
<dependency>
<dependentassembly>
<assemblyidentity type=”win32″ name=”Microsoft.VC80.ATL” version=”8.0.50727.762″ processorarchitecture=”x86″ publickeytoken=”1fc8b3b9a1e18e3b”>
</assemblyidentity>
</dependentassembly>
</dependency>
</assembly>

In my work, I’ve had very little need for manifests. The VC optimizer is able to strip the unused portions of statically linked ATL out of your code, leaving a much smaller footprint than the entire assembly would require. This eliminates the need to redistribute ATL with your application, thus reducing the overall potential for deployment issues. Nevertheless, there are exceptions to every rule, and your mileage may vary.

I’ll take web sites for $200, Alex: Part II

(continued from Part I)

The kind of web site I wanted to create is usually built on top of a Content Management System (CMS) that becomes the administrative user interface as well as the framework for web pages that get served to web site visitors. The first thing I learned is that there are *thousands* of CMS products floating about the internet, from simple “guest book” type scripts to full blown corporate extranet management systems designed for use by tens of thousands of employees and customers. I’ve also been looking for an excuse to learn ASP.NET, so I decided to narrow my search to CMS software that was based on ASP.NET. Finally, the software had to be free or very inexpensive.

Based on these criteria, I narrowed the choices down to Community Server [now Telligent Community], DotNetNuke, Rainbow Portal, and newcomer FlexCMS. Community Server is free for personal use, but for my planned use it would have cost several hundred dollars — probably out of my range, but I still downloaded and tested it for comparison purposes. DotNetNuke is open source based on a permissive BSD-style license (free to use or modify for any purpose), plus it has a large and relatively mature user base. Rainbow Portal is released under the LPGL license, with discussions currently underway about changing the license. Both DotNetNuke and Rainbow Portal are based on a Microsoft sponsored sample ASP application called IBuySpy. Rainbow Portal seemed more polished, but I ran into some limitations with both pretty quickly. FlexCMS, while seemingly more logically designed and built from the ground up on the latest version of ASP.NET, was clearly lacking a lot of features that the other two free packages included. In the end I chose DotNetNuke because it had a more permissive license and a larger user base to draw support from (I found the documentation for all these packages fairly useless, so peer support was a must).

Next step was finding an inexpensive web host that would enable me to install, run, and administer an ASP.NET/SQL Server application. If you’ve ever looked for a web host, you’ll know that it’s sometimes difficult to find one that provides the remote management capabilities and server software that you need (in my case ASP.NET and SQL Server running on IIS, which are less common than PHP/MySQL solutions running on Linux). I’m aware of several quality hosting companies. Pair networks usually gets good reviews, but they don’t do Windows. I’ve used GoDaddy before for registering domain names without any problems, so I headed there to check out their prices and policies for hosting plans. When I saw that they offered a Windows based economy plan with plenty of storage space and bandwidth for $3.19 per month, I decided to just register my new domain name and sign up for GoDaddy’s shared hosting plan on the spot, and be done with it.

Total cost for DotNetNuke CMS software, 2 years of web hosting, and a new domain name registered for two years: $88. Not bad. In Part III I’ll show you how DotNetNuke works.

I’ll take web sites for $200, Alex: Part I

I’m one of those throwbacks that learned HTML by typing it in Notepad. I’ve since moved up to using the Visual Studio editor; it does syntax coloring, error highlighting, and has a “design” mode for previewing the page, yet it’s a very utilitarian editor that I feel comfortable with. I do use FrontPage when I need to manage connections between multiple HTML pages, but mostly in raw HTML mode. When I use WYSIWYG design mode in FrontPage, I inevitably end up cleaning out a lot of unnecessary junk that it includes in the generated HTML. I think it’s fair to say that my obsession with clean HTML results in utilitarian, functional, and standards conformant presentations — but with a decided lack of graphic appeal.

The ManuSoft and CADLock web sites are examples of this utilitarian approach. The ManuSoft site uses no fancy graphics and relies very little on client side scripting, and it supports a hierarchical navigation system using only standard hyperlinks. I like that minimalist approach, but the price for clean HTML being served to clients is a lot of work on the server to maintain the site. As a result, I don’t update the site very often because it’s just too difficult.

This blog was the first step toward realizing a goal of making it easier to add new content. After all, the raison d’être of blogs is to minimize the latency between the writer’s stream of consciousness and words on the web by making it irresistibly easy to add new content. This is precisely why blogs have become so popular.

Unfortunately, I soon found limitations with my blog. Tabular lists of data still require manual HTML input, it is difficult to customize the content area outside the individual posts on the blog page, and most aspects of the hosted blog software are outside my control. I wanted more.

The Autodesk vs. Open Design Alliance lawsuit gave me an excuse to take the next step: implement the “blog” concept across an entire web site with software that I control. So, I decided to swallow my pride and learn how to create an entire web site that would be so easy to update that I would actually update it frequently — even if it meant messy HTML code. Stay tuned for Part II, choosing a hosting service and deciding which software to use.

VCBuildHook updated for VS 2005 SP1

I’ve installed Visual Studio 2005 SP1 and have been busy testing all my projects to make sure they didn’t break. Microsoft did fix at least one of the bugs I reported (the resource editor choked on resource strings that contained an embedded NULL character), but the IDE still crashes fairly consistently if I initiate a large solution build while the Intellisense database is being rebuilt. SP1 also managed to break my VCBuildHook utility, so I’ve uploaded an updated version (2.0.3.0) for use with SP1.

Visual Studio Version Hunt

If you’ve been programming with ObjectARX for a while, you already know that each version of the ObjectARX SDK only works with a specific version of Visual Studio. Mazhar Basa touches on the subject in his article Components of ObjectARX Applications. My VCBuildHook utility makes it possible to build for multiple target AutoCAD versions from a single Visual Studio 2005 solution, but this utility still needs the older versions of Visual Studio to be installed on the same system in order to perform its magic.

The problem is, legitimate licenses of older versions of Visual Studio are hard to come by. Back in the Visual Studio .NET 2003 days, you could purchase a new license of VS 2003, then get a free license downgrade from Microsoft that allowed you to install Visual Studio 2002 side by side on the same system. That combination allowed you to target AutoCAD versions as far back as AutoCAD 2004. Unfortunately, Microsoft stopped offering the VS 2002 downgrade license when Visual Studio 2005 began shipping in November of 2006.

The end result is that new ObjectARX programmers are faced with a dilemma if they need to target anything older than AutoCAD 2007. One of the attendees at my “High-Octane ObjectARX” class at AU 2006 reminded me that MSDN (Microsoft Developer Network) members can download older versions of Visual Studio from the MSDN subscriber download center.

I have verified that Visual Studio .NET 2002 (VS 2002) is available for download to MSDN Professional subscribers, but I could not find Visual Studio 6.0, which is required to target AutoCAD 2000 – 2002. Visual Studio 4.2 (required for AutoCAD R14) is available though, so maybe I’m just not looking in the right place.

If you are a professional software developer, whether commercial or in-house, you should consider subscribing to MSDN for various reasons. If you’re an ObjectARX programmer and need to target older versions of AutoCAD, MSDN may be the only way to obtain the older Visual Studio build tools and libraries that you’ll need.