New in .NET 2.0 for Windows Forms applications is a deployment feature known as “Registration-Free COM.” This allows you to use and deploy certain COM components such as ActiveX controls to client computers without registering the component on the local machine with your installer or manually using regsvr32.exe, with some limitations.
The DsoFramer control allows you to embed and control applications such as Microsoft Office programs directly inside your Windows Forms application. For example, your users might need to interact with or preview an Excel spreadsheet containing sales data, or perhaps preview a generated form letter created by Word. Until Microsoft releases a more fully supported .NET control (ActiveDocumentHost, anyone?), the DsoFramer is your best bet today for hosting unmanaged Office applications inside your Windows Forms client.
To enable Registration-Free COM for the DsoFramer control within your Visual Studio .NET 2005 project, simply right-click your unmanaged project reference, select Properties, and then on the properties panel for the reference, set “Isolated” to “True”. This will tell Visual Studio to generate a COM registration manifest for your application with the information necessary to activate and launch your unmanaged control.
By using this deployment feature new to .NET 2.0, you can in certain cases, enable your application to support XCOPY or ClickOnce deployment, where you otherwise would have to rely on a traditional setup project or manual registration for deployment.
[tags: dsoframer, registration free com, regfreecom, smart clients, clickonce, xcopy]
Next Thursday (9/22) MSDN Events will host a half-day seminar covering important areas such as UI development, data access, and building high performance apps with ASP.NET 2.0.
For more information and to sign-up, visit:
Rule the Web with ASP.NET 2.0
ASP.NET is a powerful framework for building dynamic, high performance, data-driven Web applications. ASP.NET 2.0 improves on its predecessor by helping you become more productive, reducing the amount of code you need to write, making your Web sites easier to manage, and improving your Web site’s scalability, reliability, and performance. In this three-part tour-de-force, you’ll explore valuable aspects of ASP.NET 2.0 – from user interfaces to data access to performance – that will help you create better Web applications with less hassle than ever before.
For those of you eager to get your hands on the latest and greatest Beta 2
compatible bits for Indigo and Avalon, head on over to the MSDN download
page and get ready to have some fun! If you’re
interested in using MSMQ as a transport for Indigo queued channels, you might be interested in MSMQ 3.5
beta, available here.
Btw, the new Beta 2 door hangers that have been appearing in magazines is pretty
cool… unfortunlately, though, it doesn’t seem to keep people out!
Recently, I came across an interesting and cryptic runtime error message for my Windows Forms application after I did an xcopy deployment. The error dialog was from the “Common Language Runtime Debugging Services“ and informed me that, for some unknown (and unspecified) reason my application generated an unhandled runtime error and could not continue.
The error dialog did not specify any detailed reason for the failure, and simply refused to execute my program any further. This error puzzled me and, even though I had some good diagnostic code embedded throughout the application, no diagnostics were being generated. It led me to believe that the problem was not within the program itself, but possibly a error generated during the process of loading one of my referenced assemblies.
To find out more, I setup a test deployment environment using VMWare that mirrored my target deployment environment. One of the main advantages of using VMWare is that you can set up multiple “virtual machines” to test your software deployment under various operating systems and software configurations. Even more nifty is the ability to specify a baseline image as non-persistent — meaning that any changes you make during a session are discarded after you power down the virtual machine. That makes it great to test and tweak to your hearts content, without worrying about restoring your environment to a pre-test state.
After deploying my application to the virtual machine, I ran it and it failed again with the not so friendly CLR debugging services error dialog. Puzzled, I searched Google Groups for some enlightenment and came across a post by Frank Racis who suggested launching the application from the command prompt and redirecting the stderr output to the console, which generated a text file for me with the stack trace of the entire exception message. Thanks to this tip I quickly discovered that the CLR was unable to load one of my referenced dlls because it failed the strong name validation. (For more information about redirecting your input, output, and error streams see “Using command redirection operators” in Windows Help).
It’s too bad that the CLR error dialog could not give me any more information than what it did without having to resort to redirecting the output to the console. Even worse is that there doesn’t seem to be any way that I can avoid this problem in the future (or at least customize the dialog to fail gracefully and report the error in a more helpful way). Hopefully this tip will save you similar frustration in the future if this problem ever pops up in one of your applications.
Head on over to Microsoft’s Get The Betas page and order your copy for free while supplies last. You can also sign up to receive alerts of Visual Studio 2005 and SQL Server 2005 educational events and release details. (Thanks to Brian Keller of Coding4Fun fame for the link!)