Software: Running Excel with .NET 1.1 Code-Behind

Working programmatically with Microsoft Excel is always fun because it’s sort of the ugly stepchild. I’ve been working on making sure that our samples still work in Visual Studio 2003 and suddenly, **throat clearing**, I was no longer able to debug the Excel with code-behind sample. So of course I dug around for answers...

I turned up this group posting: “VS 2003 to VS 2005 UPGRADE w/Excel 2003, VSTO”. Ken states that you can experience Excel debugging problems if you have both Visual Studio 2003 and Visual Studio 2005 installed. He suggests either porting the application to Visual Studio 2005 or creating an Excel config file specifying that you want to use .NET 1.1 for the Excel application and consequently debugging. I’m going to have to create an application config file to debug in Visual Studio 2003 and remember to remove it when I port the sample to the .Net 2.0 version and test in Visual Studio 2005. What a pain.

So the next thing to figure out was what’s in an excel.exe.config file and where does it live. This information can be found at ”Side-by-Side Execution of the .NET Framework”.

By putting the file excel.exe.config in the same directory as my excel.exe file I am able to once again use Visual Studio 2003 to debug an Excel application.

And here are the contents of my excel.exe.config:

<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v1.1.4322"/>
</startup>
</configuration>

And I am now able to debug my Excel sample.

But that wasn’t all; there is more to Excel with .NET 1.1 code-behind. I wasn’t able to instantiate an object that was defined by the Digipede Framework. The DigipedeClient object in particular. I got the following message:

An unhandled exception of type 'System.Security.SecurityException' occurred in digipede.framework.dll

Additional information: Request for the permission of type System.Security.Permissions.StrongNameIdentityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.

What this means is that my Excel project wasn’t given the permissions it needed to run. So I had to go into the .NET Configuration 1.1 Wizard and add my Excel project under “Runtime Security Policy\User\Code Groups\All_Code\Office_Projects”. Once I had the correct .NET libraries in use and the security policy problem cleared up, I was good to go.

Technorati tags: Excel, Code-Behind, VBA, .NET 1.1, .NET 2.0, Microsoft