By Randy Moore - 2/7/2007
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()
|
By Trent L. Taylor - 2/8/2007
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
|
By Victor Sousa - 3/19/2010
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??
|
By Victor Sousa - 3/19/2010
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.
|
By Ivan George Borges - 3/19/2010
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.
|
By Victor Sousa - 3/19/2010
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.
|
By Ivan George Borges - 3/19/2010
This looks like a security issue. Both EXEs are the same name, right? This is not a firewall thing with exceptions and such...?
|
By Victor Sousa - 3/19/2010
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?
|
By Victor Sousa - 3/19/2010
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.
|
By Victor Sousa - 3/19/2010
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.
|
By Trent L. Taylor - 3/23/2010
This is a relatively simple file and should not be based on your assembly version. There are two things that happen in the creation of this file. First, there is an XML file that is built. Once built, it is then written to disk and encrypted. The encryption shouldn't store the SF assembly version as a vector key is used as the seed for the encryption.
So I am not sure why an assembly version is being embedded in the file. What assembly version did you change that caused the behavior?
|
By Victor Sousa - 3/23/2010
I updated the assembly version of the EXE file.
I looked at the SF Framework source and traced based on the error message to the following call:
loDS = OpenXMLFileInMemory(System.Reflection.Assembly.GetEntryAssembly().GetName().Version.ToString(), TableName, PathAndFileName, ColumnStructure, loMemStream, llNeedsEncryption)
if the versions do not match it tries to recreate the file with the new version.
|
By Victor Sousa - 3/23/2010
Ok, some more information. I've reproduced this on my Development machine. Slightly different Error, but i believe it still has to to with the Assembly Version.
I have two EXEs with the same exact code. The only difference is that the first has assembly version 1.0.0.0 and the second has assembly version 2.0.0.0.
I have two connections, so I create two shared settings files with version 1 using the shared settings file wizard. Everything works great. I then run version 2 of the EXE and it goes in fine the first time. The second time I run version 2 i get the following error:
XmlException
Invalid character in the given encoding. Line 1, position 1.
Source : System.Xml
Stack Trace:
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.InvalidCharRecovery(Int32& bytesCount, Int32& charsCount)
at System.Xml.XmlTextReaderImpl.GetChars(Int32 maxCharsCount)
at System.Xml.XmlTextReaderImpl.ReadData()
at System.Xml.XmlTextReaderImpl.SwitchEncoding(Encoding newEncoding)
at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl)
at System.Xml.XmlTextReaderImpl.Read()
at System.Xml.XmlReader.MoveToContent()
at System.Data.DataSet.ReadXml(XmlReader reader, XmlReadMode mode, Boolean denyResolving)
at MicroFour.StrataFrame.Xml.XmlBasics.OpenXmlFileInMemory(String CurrentVersion, String TableName, String PathAndFileName, List`1 ColumnStructure, MemoryStream& DataStream, Boolean& NeedsEncryption)
at MicroFour.StrataFrame.Xml.XmlBasics.OpenXmlFileInMemory(String TableName, String PathAndFileName, List`1 ColumnStructure, Boolean DecryptFile)
at MicroFour.StrataFrame.Data.BusinessObjects.DbeSharedSettingsData.FillWithSharedSettings(String PathAndFileName)
at MicroFour.StrataFrame.Data.ConnectionManager.VerifySharedSettings(DbeApplicationData ApplicationData, DbeConnectionData ConnectionData)
at MicroFour.StrataFrame.Data.ConnectionManager.EvaluateConnections(DbeApplicationData ApplicationData, DbeConnectionData ConnectionData)
at MicroFour.StrataFrame.Data.ConnectionManager.SetConnections()
at GKGInc.POAnalysis.Program.SetDataSources()
at MicroFour.StrataFrame.Application.StrataFrameApplication.RunApplication()
at GKGInc.POAnalysis.Program.Main()
The SSF files date have changed when i ran version 2.
Now, version 1 doesn't work either and throws the same error. Version 1 and Version 2 do not work throwing error above.
It looks like running version 2 corrupted the SSF files.
|
By Victor Sousa - 4/15/2010
Anyone have any information on this?
I'm using the file version as a work around for now, but I would like to know why this is happening in my situation if the shared settings file should not be affected by the assembly version.
|
By Trent L. Taylor - 4/15/2010
We will try and setup this up. It sounds like a serialization issue between assemblies. There is actually a way to address deserialization between assembly versions and my guess is that the issue is no your assembly, but possible the different in an older SF 1.6 assembly versus a 1.7 assembly. We will try that scenario instead as your assembly version should not be a factor.
|