Saxon

Legacy ID: #4409330 Legacy Poster: Michael Kay (mhkay)

Sorry, I have no idea what might be wrong here. I can't see any intrinsic reason why what you're doing shouldn't work. I think I would try re-installing - I know that's rather pathetic advice in the absence of any diagnosis of the problem, but it does feel as if you have somehow corrupted the software installation. Michael Kay

Legacy ID: #4409402 Legacy Poster: Timothee Bastin (timothee)

Thank you for the quick response. I experienced this problem yesterday at a customer's system and can simulate it in my VMware environment. Of course reïnstalling could solve the problem, but that's not a structural fix :) I think I already found that it is a .NET Framework problem....it has to do something with the local security settings I guess. Good to know though that it normally should work for Saxon, so that's not the problem.

Legacy ID: #4410420 Legacy Poster: Timothee Bastin (timothee)

It definitely is a problem with the security settings of the .NET Framework. Drivemappings are categorized in the security zone local intranet. This zone has some restrictions which the local computer zone does not have (that's why it works well on a local drive). When I change the settings for the local intranet zone to no restrictions, Saxon is working fine from a mapped drive! Of course this is not a good idea (security issues), but at least I know what the problem is. Next problem is how to get Saxon trusted by .NET from a mapped drive. I already found some interesting info on the net, but it doesn't seem to work yet :( None of you has ever tried to work with a similar situation?

Legacy ID: #4410423 Legacy Poster: Michael Kay (mhkay)

Thanks for the info. If you come up with useful advice that will help others, let's add it to the Wiki. FYI, if you want a conversation with other Saxon users, the mailing list works much better than this forum. Not many users monitor the forum.

Legacy ID: #4410555 Legacy Poster: Timothee Bastin (timothee)

I've just found this page: http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx A lot of useful information on this page, explained in an easy to understand way :) From the three ways to make Saxon work from the LocalIntranet zone, I think only the third option will work at the moment and that is the option I already used (which isn't a safe option; I won't suggest that to clients). The recommended way is to use strong names. I'm totally new to .NET and I'm not a programmer, so it is a bit of abacadabra for me but I guess it is something that has to be done by the developer of the application I'm trying to run (that must be you ;) ). I will add the working option to the Wiki tomorrow. Maybe I will send my question to the mailing list too...hopefully anyone has already faced this problem and managed to get it working.

Legacy ID: #4410599 Legacy Poster: Timothee Bastin (timothee)

Well, here I am again :) I think I've found a good solution, thanks to a reply on the article I posted in the previous message. Here the steps you have to take to let .NET Framework 1.1 trust your Saxon folder on your network share (I'm translating the screens from Dutch, so I don't know if all names are correct): - Start the Configuration panel in Windows - Go to the Administration Tasks panel - Select the Microsoft .NET Framework 1.1 Configuration option - Expand the Runtime Security Policy folder - Expand the Machine policy level - Expand the Code Groups folder - Right click on All-Code and select New - Create a new code group, for example "Saxon" - Click next and select as condition the URL option - Give the URL of the shared folder, in my example: file://TBA4200/D$/Saxon/* (all subfolders of this URL are granted too) - Click next and grant your new group "FullTrust". - Save the group and execute Saxon from the network share...in my case it worked :) Although this option is not absolutely secury too, I think it is much better then just granting the LocalIntranet zone "FullTrust". I will add this one to the Wiki too.