C# File.Create terminating WimForm app wiith no error thrown ?
-
Do you know what the filename is at that point? I'm not sure what you were trying here, but that fullfilename creation line looks dodgy; it could just be the way you entered it here. You don't need to delete a file before you call File.Create. If you call File.Create on an existing filename, it will overwrite the existing file.
Hi Pete, Thanks, I double-checked using a hard-coded file name: same behavior observed; serializing to xml works, to gz closes app. fyi: in output window after app closed: has exited with code 0 (0x0). It may interest you to know that the original idea for my library came from code you posted here in 2015 in response to a question on serializing a TreeNode [^] :) Strange that I can't see your code for serializing on that thread now.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Hi Pete, Thanks, I double-checked using a hard-coded file name: same behavior observed; serializing to xml works, to gz closes app. fyi: in output window after app closed: has exited with code 0 (0x0). It may interest you to know that the original idea for my library came from code you posted here in 2015 in response to a question on serializing a TreeNode [^] :) Strange that I can't see your code for serializing on that thread now.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
I've tried your code with a hardcoded path and it works okay for me. The only failure I get is if I write to a protected location, or to a directory that doesn't exist.
-
I've tried your code with a hardcoded path and it works okay for me. The only failure I get is if I write to a protected location, or to a directory that doesn't exist.
Thanks, Pete, Since saving XML to the same directory works, I can exclude the possible file errors you mention ... which I'd expect to throw errors. Here's something really strange: after installing the latest VS 2019 Community update, to Version 16.11.11 ... the code worked once .. after that same behavior as before. Same app opened in VS 2022 latest: same fail. There's one possible wild-card here i'll test today: PostSharp is installed in this solution (licensed version), although the code I am testing does not use it. Will start a new solution w/o PostSharp and ReSharper turned off, and re-test. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Update: revised code to use full Type names, not var; used hard-coded filepath. Now, in VS 2019 using FW 4.8, File.Create terminates the app with no error message. I tried wrapping the call in a Try/Catch: terminates the app without ever reaching the Catch clause. Note: i can't find any error reports on the behavior of File,Create described here. A few years ago, the code shown here was a standard part of the serialization library i wrote, and worked fine. The other part of the library, which uses XML serialization, works without errors. Note: the code shown compiles, but, fails in the first 'using block. File,Create moved outside the using statement also fails the same way. So, there's nothing specifically GZippy where the code fails. // reqiured usings using System.IO; using System.IO.Compression; using System.Runtime.Serialization;
public static void GZSerialize(T instance, string baseFolderPath, string filename1)
{
dcs = new DataContractSerializer(typeof(T));string fullfilename = baseFolderPath + "/" + filename1 + (usegzip + @".gz"; //if (File.Exists(fullfilename )) //{ //File.Delete(fullfilename ); //} string fullfilename = @"C:\\Users\\Win-Ten\\Desktop\\fordata\\test4.gz"; **// fails here** using (FileStream compressedFileStream = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write)) { using (GZipStream compressionStream = new GZipStream(compressedFileStream, CompressionLevel.Optimal, true)) { dcs.WriteObject(compressionStream, instance); compressionStream.Close(); } }}
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Is it possible that you're getting a "process corrupted state" exception? Those won't be caught by a
try..catchblock unless the method has theHandleProcessCorruptedStateattribute applied. HandleProcessCorruptedStateExceptionsAttribute Class (System.Runtime.ExceptionServices) | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Is it possible that you're getting a "process corrupted state" exception? Those won't be caught by a
try..catchblock unless the method has theHandleProcessCorruptedStateattribute applied. HandleProcessCorruptedStateExceptionsAttribute Class (System.Runtime.ExceptionServices) | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Thanks, Richard, "process corrupted state" reminds me of what I see in the mirror these days :omg: I'm retesting today in a new solution with PostSharp and ReSharper not in use.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Update: revised code to use full Type names, not var; used hard-coded filepath. Now, in VS 2019 using FW 4.8, File.Create terminates the app with no error message. I tried wrapping the call in a Try/Catch: terminates the app without ever reaching the Catch clause. Note: i can't find any error reports on the behavior of File,Create described here. A few years ago, the code shown here was a standard part of the serialization library i wrote, and worked fine. The other part of the library, which uses XML serialization, works without errors. Note: the code shown compiles, but, fails in the first 'using block. File,Create moved outside the using statement also fails the same way. So, there's nothing specifically GZippy where the code fails. // reqiured usings using System.IO; using System.IO.Compression; using System.Runtime.Serialization;
public static void GZSerialize(T instance, string baseFolderPath, string filename1)
{
dcs = new DataContractSerializer(typeof(T));string fullfilename = baseFolderPath + "/" + filename1 + (usegzip + @".gz"; //if (File.Exists(fullfilename )) //{ //File.Delete(fullfilename ); //} string fullfilename = @"C:\\Users\\Win-Ten\\Desktop\\fordata\\test4.gz"; **// fails here** using (FileStream compressedFileStream = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write)) { using (GZipStream compressionStream = new GZipStream(compressedFileStream, CompressionLevel.Optimal, true)) { dcs.WriteObject(compressionStream, instance); compressionStream.Close(); } }}
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Bill, Check to see if Controlled Folder Access[^] is causing the issue. I think you had a similar error a few years ago[^]. :) Best Wishes, -David Delaune
-
Bill, Check to see if Controlled Folder Access[^] is causing the issue. I think you had a similar error a few years ago[^]. :) Best Wishes, -David Delaune
Thanks, David, I think I can exclude that hypothesis based on the fact that using standard DataContract/DataMember serialization to XML to the same folder is reliable. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Thanks, David, I think I can exclude that hypothesis based on the fact that using standard DataContract/DataMember serialization to XML to the same folder is reliable. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Ok, Just keep in mind that Windows Defender now performs behavioral analysis so it might allow certain actions while blocking others. Good Luck. :)
Thanks, David, I have checked both Win-Def and EmsiSoft (my active malware filter/firewall), no evidence for this rather improbable scenario. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Thanks, David, I have checked both Win-Def and EmsiSoft (my active malware filter/firewall), no evidence for this rather improbable scenario. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Alright, Then you should have no problems determining why your process is exiting. Did you try to attach a debugger? Did you check the event log and get the exit code[^]? Have you tried using Gflags[^]? The path you gave in your top level post:
string fullfilename = @"C:\Users\Win-Ten\Desktop\fordata\test4.gz";
would be protected by controlled folder access (if enabled). Best Wishes, -David Delaune
-
Alright, Then you should have no problems determining why your process is exiting. Did you try to attach a debugger? Did you check the event log and get the exit code[^]? Have you tried using Gflags[^]? The path you gave in your top level post:
string fullfilename = @"C:\Users\Win-Ten\Desktop\fordata\test4.gz";
would be protected by controlled folder access (if enabled). Best Wishes, -David Delaune
Thanks, David, but, the convers you are raising have alrady been addressed, and should be obvious if you read the previous messages.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Update: revised code to use full Type names, not var; used hard-coded filepath. Now, in VS 2019 using FW 4.8, File.Create terminates the app with no error message. I tried wrapping the call in a Try/Catch: terminates the app without ever reaching the Catch clause. Note: i can't find any error reports on the behavior of File,Create described here. A few years ago, the code shown here was a standard part of the serialization library i wrote, and worked fine. The other part of the library, which uses XML serialization, works without errors. Note: the code shown compiles, but, fails in the first 'using block. File,Create moved outside the using statement also fails the same way. So, there's nothing specifically GZippy where the code fails. // reqiured usings using System.IO; using System.IO.Compression; using System.Runtime.Serialization;
public static void GZSerialize(T instance, string baseFolderPath, string filename1)
{
dcs = new DataContractSerializer(typeof(T));string fullfilename = baseFolderPath + "/" + filename1 + (usegzip + @".gz"; //if (File.Exists(fullfilename )) //{ //File.Delete(fullfilename ); //} string fullfilename = @"C:\\Users\\Win-Ten\\Desktop\\fordata\\test4.gz"; **// fails here** using (FileStream compressedFileStream = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write)) { using (GZipStream compressionStream = new GZipStream(compressedFileStream, CompressionLevel.Optimal, true)) { dcs.WriteObject(compressionStream, instance); compressionStream.Close(); } }}
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
@Randor Thanks to David (aka Randor) ! Well, turns out I did not look deeply enough into the EmsiSoft AV/Firewall records, as David suggested. Note: size of test file saved as .xml 1017; size saved as .gz 369. EmsiSoft was quarantining the WinForm app .exe. I set permission for the entire folder containing my C# work in progress ...code works ... ... setting permission for VS 2019 and 2022 had no effect. Why the whole folder ? I was too lazy to set it for one specific project. Here's what the kinks were: 1. no run-time notification pop-up from EmsiSoft which is normally ... a frequent popper-upper. And, once quarantined, why should the app run partially at all ? I will write about this to them, and, aaso ask them what could happen if I were using GitHub storage. 2. why should standard XML writing:
using (var writer = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write
//FileIOPermissionAccess.AllAccess
))
{
dcs.WriteObject(writer, instance);
}work, but, why does this:
using (FileStream compressedFileStream = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write))
{
using (GZipStream compressionStream =
new GZipStream(compressedFileStream, CompressionLevel.Optimal, false))
{
dcs.WriteObject(compressionStream, instance);
compressionStream.Close();
}
}trigger AV interception ? Is there an MS bug here ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
@Randor Thanks to David (aka Randor) ! Well, turns out I did not look deeply enough into the EmsiSoft AV/Firewall records, as David suggested. Note: size of test file saved as .xml 1017; size saved as .gz 369. EmsiSoft was quarantining the WinForm app .exe. I set permission for the entire folder containing my C# work in progress ...code works ... ... setting permission for VS 2019 and 2022 had no effect. Why the whole folder ? I was too lazy to set it for one specific project. Here's what the kinks were: 1. no run-time notification pop-up from EmsiSoft which is normally ... a frequent popper-upper. And, once quarantined, why should the app run partially at all ? I will write about this to them, and, aaso ask them what could happen if I were using GitHub storage. 2. why should standard XML writing:
using (var writer = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write
//FileIOPermissionAccess.AllAccess
))
{
dcs.WriteObject(writer, instance);
}work, but, why does this:
using (FileStream compressedFileStream = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write))
{
using (GZipStream compressionStream =
new GZipStream(compressedFileStream, CompressionLevel.Optimal, false))
{
dcs.WriteObject(compressionStream, instance);
compressionStream.Close();
}
}trigger AV interception ? Is there an MS bug here ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
@Randor Well, Sir, i think it is ... You ... who solved it ! :) But, please indulge my OCD re language: i do consider understanding the source of an anomaly as not equatable with "solved." Yet, it was moi who used thr word "solved: :omg: End of rant. What a wonderful education code that worked for years ... and then, breaks ... can offer :) Please come to Chiang Mai asap so i can take you for a scrumptious Thai dinner. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
