Chris McKenzie's Blog

I'm the Source Safe admin in my department, and there are applications that we have that were written in Visual Dataflex 7. We're adding those applications to source safe, but I don't really know anything about Visual Dataflex.  I figured I'd ask if any of you knew whether or not there was any support for Visual Sourcesafe integration in Visual Dataflex 7. 

Thanks

On my previous post regarding security, I got this comment from weblogs.asp.net/ptorr:

"unfortunately if it is easy for you to get your code to run, it will be easy for attackers to get their code to run."

I guess if it's difficult for me to get my code to run, then it is difficult for me to justify spending the time to write code for VSTO.  Before I get too deep into my suggestions for possible alternative approaches, let me first say that I realize that VSTO is a v1 product and has room to grow.  I'm offering my comments, criticisms, and suggestions in the hope that they will have some impact on the way that VSTO develops.

The goal that underlies these suggestions is two-fold: First that .NET security should exist, and second, that it shouldn't get in my way.  My suggestion would be as follows: Let the document establish permissions for the assembly.  In other words, if I act to open a document that has VSTO extensions, then the document knows where the assembly is located, and should be able to check to see if it has appropriate permissions to run.  If it doesn't, then the document should prompt the user to that effect, warn them of the dangers of running untrusted code, ask if the the assembly should be granted FullTrust on a permanent or temporary basis, and then set the appropriate security policy automatically.  It shouldn't matter whether the document is running on the local machine or over the intranet in this scenario.

Another scenario would be to provide a security setup project for VSTO solutions.  The setup program should have two behaviors: 1) to install documents on the local machine, or 2) to set the local machine up to run documents from an intranet location.  In the first case, the setup program should deploy the documents to the specified location, establish the correct permission set so that they can run, and close.  In the second case, the setup program should prompt the user to navigate to the assembly on the intranet that is being configured, and set the appropriate permissions.

The advantage to either of the above models is that MS can validate that the user has the appropriate Machine and Intranet permissions to perform the security changes.

I guess my argument boils down to this: if Office is going to support .NET Framework development, then make Office support .NET Framework development. There's no reason that I can see that we can't have security and deployable solutions. 

As always, please correct me where I'm wrong.

Which File Extension are You?

I especially like the "working with amateurs" comment.  I may have my limits, but I don't think I've found them yet :)

The installer was at the client's, installing our VSTO application, and was getting the following error:

"The current .NET security policy does not permit <document> to load custom macros."

The VSTO Troubleshooting page says that the reason for this is that the document was opened from an untrusted location, or from an email attachment. It also mentions as a possibility that the wrong version of the .NET Framework might be running on the machine. After checking the .NET Security Configuration Settings (by phone, arghh!) and getting no results, I started thinking about what is meant by "an untrusted location."  Does it mean that the location of the .NET assembly being loaded by the document is untrusted? No because I had explicitly set the trust level on the dll.  What could it mean then?

...

Eureka!  I'm attempting the run the documents over the intranet!  The Machine->LocalIntranet_Zone has to have FullTrust permissions!  Switch those on and the documents begin working.

Okay, so here's the invitation to the rest of you that are deploying VSTO solutions: Is there anything fundamentally wrong with the approach I took?  Is there something better I could have done?

As an aside:

To Microsoft--

I'm a big fan.  I hope even to join your ranks in Redmond someday.  The .NET Framework is a marvelous achievement, and I am thrilled to see it being integrated with Office.  This brings a level of power to Office Development that had never existed before. It makes it easy to integrate existing and varied solutions with Office documentation, thereby making Office an even more attractive suite of software for business management.  That said, the hoops I have to jump through as a VSTO developer to deploy my Office solutions are too many.  The fact that the client has to have Office 2003 Pro even to make use of these features is a huge detriment to the cause.  The fact that .NET Security Configuration is such a bear, and that there's no clean programmatic way to manipulate it, makes it difficult to justify the trouble. You've created a wonderful set of tools that allow me to provide powerful business software to my clients.  Please, ease the burden of the license and security requirements so that I can continue to work with these tools.

Thank you.