Hi,

I'm trying to run an application remotely. The host has Windows 2000 and .NET Framework 2.0 installed. We also have SQL Server Express running on XP. When I try to execute the program I get this error. It run's fine on my development computer and on the computer running SQL Server Express. Any ideas why this might be happening? 

UnauthorizedAccessException
 Access to the path is denied.

Source     : mscorlib

Stack Trace:
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.__Error.WinIOError()
   at System.IO.File.Move(String sourceFileName, String destFileName)
   at MicroFour.StrataFrame.Security.Encryption.TripleDESWrapper.TransformFile(String FileName, ICryptoTransform CryptoTransform)
   at MicroFour.StrataFrame.Xml.XmlBasics.OpenXmlFile(String Version, String TableName, String PathAndFileName, List`1 ColumnStructure, Boolean DecryptFile)
   at MicroFour.StrataFrame.Data.BusinessObjects.DbeApplicationData.FillAll()
   at MicroFour.StrataFrame.Data.ConnectionManager.SetConnections()
   at Project_Tracker.AppMain.SetDataSources()
   at MicroFour.StrataFrame.Application.StrataFrameApplication.Raise_SetDataSources()
   at MicroFour.StrataFrame.Application.StrataFrameApplication.RunApplication()
   at Project_Tracker.AppMain.Main()

This has to do with how your security is setup within the remoting application.  This really doesn't have anything to do with StrataFrame.  I recommend looking at some of the Microsoft articles regarding this topic:

http://msdn2.microsoft.com/en-us/library/ms973911.aspx 

I'm getting this same error with an update i just put out at a customer.



I get the error twice, once for each SSF file that i am using. Configuring the connections without using the Network shared settings file works fine.



If i revert to the prior version of the application it works fine even with the Shared Network settings file.



I did add some code to Main() in the program.cs that checks for updates. This rung before the RunApplication() call. It seems to be running through that code without a problem, and according to the Trace is happening in the SetConnections() method. Which is what led me to try configuring the connections without the SSF file.



What in my current application could have caused this change??

I've reverted program.cs to the way it was previosly, compiled and applied at Customer site. Same issue. But when I put the old EXE back, it works fine.



UUUUGH!!!!



There is something about the compiled EXE that is causing this, but i have no ideas where to look. I'm pulling at straws at this point.

Hey Victor.

Just guessing... is the old EXE running as Administrator, while the new one is not?

You can check that going to the Shortcut properties, and then Advanced button.

No, both run the same exact way. I'm at wits end here. I have no idea what has changed.



It works in my development environment, but not in customer's environment. It must be some combination of the build and their environment. If both EXEs didn't work then I would say it was strictly something that changed in their environment.

This looks like a security issue. Both EXEs are the same name, right? This is not a firewall thing with exceptions and such...?

Both have the same exact name. Customer's Network admin said nothing has changed with security. I would think that both EXE's would have the issue if it was a security issue, No???



According the Stack Trace, is it happening at this call?

System.IO.File.Move(String sourceFileName, String destFileName)



I'm assumiong the sourceFileName is my DSS file.

Any way to find out where the destFileName is?

I started looking at the SF source code that is mentioned in the Stack Trace and found that the Assembly version is used when building the encrypted shared connection file.

That was changed in my latest version. I am going to build the exe with the same assembly version as before and put it out there to see what happens.

That was it!!!!!!!!!!!!!!!!!!!!!!!!!!!!!



i built the exe with the same Assembly version and it is now working.



Apparently because it saw the different version, it tried to create a new encrypted file and that is what was failing.



This leads to another question....



Do i need to recreate my Shared settings files every time my Assembly version changes??



Am i not following procedure correctly? That just doesn't seem right.