S h o r t S t o r i e s

// Tales from software development

Archive for May 2009

.NET 3.5 SP1: Full Trust for .NET executables on network shares

leave a comment »

In the early days of .NET it was possible to create a .NET executable, copy it to a network share, and anyone with access to the share could run the executable directly from the share without any security issues. 

It was a very practical solution for applications used within corporate LANs but Microsoft identified a security risk and tightened things up. Network shares were categorized as belonging to the Intranet Zone within the standard .NET security implementation. This meant that you could not run a .NET executable from a network share without altering the local machine’s security configuration to allow this.

Things took a bizarre turn with a bug introduced with Internet Explorer 6 or 7 (I can’t remember which) that incorrectly categorized a network share as belonging to the Internet Zone rather than the Intranet Zone. No matter how much the Intranet Zone security settings were tweaked to allow code execution, the application on the network share would fail with a security exception. One of the possible solutions was to add the network share to the Trusted Sites list in Internet Explorer. This forced the re-categorization of the network share from the Internet Zone to the Intranet Zone. No, I’m not making this up!

Even without that particular bug, changing the security configuration for every machine that you wanted to run the executable on was a nuisance and cancelled out the convenience of using a network share this way.

But, with .NET 3.5 SP1, this issue has come full circle – Microsoft has moved network shares into the default Full Trust security group. So, once again, .NET executables will run directly from a Network share without any changes to the local machine’s default security configuration.

Thanks Microsoft, good call.


Written by Sea Monkey

May 20, 2009 at 8:00 pm

Classic CompuServe

with 2 comments

Last month I mentioned that I’d received an email from CompuServe informing me that the Classic service was being shutdown and I’d have to migrate my email address to a new server that CompuServe was setting up.

Yesterday another email arrived to say that I needed to access a page on the CompuServe web site to activate a new account for my old email address.

To cut a long story short – it was one problem after another. A few problems that occurred along the way:

  • The web page wasn’t yet set up to handle the migrations so the instructions in the email didn’t work. I suspect this may have been a time zone issue but plenty of other users had the same experience.
  • Late in the day, UK time, the web page was updated and I was able to login. The instructions were still wrong and the migration process started automatically rather than requiring the user to manually select this option.
  • After the migration process appeared to complete and I was able to access the new email account using CompServe’s web mail interface, I tried to configure my email client to access the account using POP3. The instruction email was unclear about the format of the username that should be used. I tried several permutations and got varying results – most were rejected by the mail server but eventually I realised that the most obvious format of the username was actually failing with a timeout rather than a rejection. This probably meant that the login authentication was working but the mail server wasn’t yet fully configured to actually be used. Possibly this was an account migration issue.
  • I decided to leave it for a few hours at least to see if this was a migraton issue and that the server just needed time for the account to be fully set up. The next day I tried it and it worked perfectly.

There are a lot of frustrated CompuServe Classic users venting their anger in CompuServe’s forums at the way that CompuServe has handled this process. Perhaps not appreciating the irony of his comment, one user’s response was: “This is classic CompuServe!”

Actually, it’s CompuServe Classic… 😉

For anyone else going through the process, this information might be useful:

  1. Open a web browser and go to http://member.compuserve.com/mailcenter
  2. Login using either your CompuServe ID or your username alias. Whichever you use will become the email address of the migrated email account. So, if you have and use an email alias then login using this otherwise you’ll lose it. The login name should be suffixed with @compuserve.com. Use the password associated with you CompuServe account.
  3. After a few seconds of flashing the page will redirect to an account set up page. Once you’ve completed this and submitted it you’ll be redirected to your new email account at http://webmail.compuserve.com. Note that you’re prompted to enter a new password for the account. I entered my existing CompuServe account password and this was accepted. So, if you’d prefer to keep your existing password, you can.
  4. You can now reconfigure your email client, if you use one, but it won’t work for about 8-12 hours. The server address is pop.csi.com as indicated in the migration email. The username is your new (well, old) email address, i.e. alias-name@compuserve.com and the password that you specified in the account set up in the previous step.

There’s some debate in the CompuServe forums about how and when the new account becomes fully active. CompuServe appear to have said that the migrated account will not receive incoming mail for the Classic email address until a switchover in June. This appears to be incorrect. My experience is that once the new account is accessible via POP3 (several hours after initiating the migration) new mail starts arriving on the new pop3.csi.com server rather than the old Classic POP3 server at pop.compuserve.com.

UPDATE: Another 24 hours on, about 36 hours after the account was migrated, and all my emails from the old email account have now appeared in the new email account.

Written by Sea Monkey

May 19, 2009 at 12:00 pm

Posted in Comment, General

Tagged with ,