Access to the path is denied

StrataFrame Forum

Back

Access to the path is denied

Author	Message
Trent Taylor	Trent Taylor posted 14 Years Ago Post Details Share Post
Group: StrataFrame Developers Posts: 6.6K, Visits: 6.9K	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.
	Reply Like 0
Victor Sousa	Victor Sousa posted 14 Years Ago Post Details Share Post
Group: Forum Members Posts: 21, Visits: 236	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.
	Reply Like 0
Victor Sousa	Victor Sousa posted 14 Years Ago Post Details Share Post
Group: Forum Members Posts: 21, Visits: 236	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.
	Reply Like 0
Victor Sousa	Victor Sousa posted 14 Years Ago Post Details Share Post
Group: Forum Members Posts: 21, Visits: 236	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.
	Reply Like 0
Trent Taylor	Trent Taylor posted 14 Years Ago Post Details Share Post
Group: StrataFrame Developers Posts: 6.6K, Visits: 6.9K	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?
	Reply Like 0
Victor Sousa	Victor Sousa posted 14 Years Ago Post Details Share Post
Group: Forum Members Posts: 21, Visits: 236	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.
	Reply Like 0
Victor Sousa	Victor Sousa posted 14 Years Ago Post Details Share Post
Group: Forum Members Posts: 21, Visits: 236	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.
	Reply Like 0
Victor Sousa	Victor Sousa posted 14 Years Ago Post Details Share Post
Group: Forum Members Posts: 21, Visits: 236	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?
	Reply Like 0
Ivan George Borges	Ivan George Borges posted 14 Years Ago Post Details Share Post
Group: StrataFrame MVPs Posts: 1.9K, Visits: 21K	This looks like a security issue. Both EXEs are the same name, right? This is not a firewall thing with exceptions and such...?
	Reply Like 0
Victor Sousa	Victor Sousa posted 14 Years Ago Post Details Share Post
Group: Forum Members Posts: 21, Visits: 236	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.
	Reply Like 0