Outside The Box blogs, Autodesk University anecdotes, articles, blog digests, and product news in chronological order. See Articles for the same material by subject.
(continued from Part II)
DotNetNuke (aka DNN) is not simple to set up. It needs at least the free SQL Server Express Edition (http://www.microsoft.com/sql/editions/express/default.mspx) on the host system (full SQL Server requires some changes to the default configuration) and either IIS or another ASP .NET 2.0 compatible web server to run on. If you have Visual Studio 2005 fully installed, you have all you need to run DNN.
…
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.
(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.
…