I know the answer must be out there somewhere, I applied suggestions both from many other questions and from MSDN itself but I'm probably overlooking something here.
This is my method, I use it to dump output to file. lock object declaration attached for clarity.
private static Object fileLock = new Object();
private static void WriteToFile(string msg, bool WriteLine)
{
lock (fileLock)
{
msg = DateTime.Now.ToShortTimeString() + " - " + msg;
FileInfo F = new FileInfo("dump.txt");
using (StreamWriter writer = F.Exists ? F.AppendText() : F.CreateText()) //<--THIS LINE THROWS
{
if (WriteLine)
writer.WriteLine(msg);
else
writer.Write(msg);
}
}
}
Question is: Why does the using line above throws an IOException complaining another process is using the file the 2nd time I call the method ?
I'm calling it like this around my code:
Console.WriteLine(something)
#if(DEBUG)
Extensions.WriteToFile(something,true);
#endif
Again, I'm sure this is a trivial issue and someone else asked something like this getting the right answer, but I'm unable to dig it up.
UPDATE
Refactoring out the FileInfo object and switching to File.XXX methods made the code work fine. I still wonder what the issue was, anyway the issue looks like solved.
#Guffa: declaration has to be private static object fileLock = new object();
#alex: Your code works just fine on my machine although it's a bit too complicated for the task imo.
static void Write(string text, string file)
{
using (StreamWriter sw = File.AppendText(file))// Creates or opens and appends
{
sw.WriteLine(text);
}
}
Maybe some antivirus or indexer locks your dump file.
Related
I created a function to make sure an object is disposed of properly. This function includes setting the object to null. I am wondering if the line that sets the object to null is useless (and hence I will remove the line), and then add a line to set the object to null in the calling function. My example is for the FileStream object, but I any other object (I think) can take its place. I know I can trace the execution of the program and see what is happening, however, I would like to know more information on the inner mechanisms (garbage collection?), does this work for any object, etc.
//Called function:
public static void DiscardFile(System.IO.FileStream file)
{
file.Flush();
file.Close();
file.Dispose();
//Does this work?
//When the function returns, is the file object really set to null?
file = null;
}
//Calling function:
public static void WriteStringToFile(string s, string fileName)
{
System.IO.StreamWriter file = new System.IO.StreamWriter(fileName);
file.Write(s);
DiscardFile(file);
//Is this redundant?
//Or is the line in the called function the redundant line?
file = null;
}
Thanks!
I have a loop that writes a thousand strings to files within 30 seconds. (The program will be writing 400K+ strings when it completes its execution.) I see that the loop waits (every so often) at the file.Write(s) line, and that the memory footprint of the app increases. That is for another thread, but wanted to know the behavior of the above code.
Thanks!
Sorry, but your implementation is dangerous
public static void WriteStringToFile(string s, string fileName)
{
System.IO.StreamWriter file = new System.IO.StreamWriter(fileName);
file.Write(s); // <- the danger is here
DiscardFile(file);
//Is this redundant? Yes, it's redundant
//Or is the line in the called function the redundant line?
file = null;
}
Suppose you have an exception thrown on file.Write(s); it means that DiscardFile(file); will never be executed an you have resource leakage (HFILE - opened file handle).
Why not stick to standard using pattern:
public static void WriteStringToFile(string s, string fileName)
{
// Let system release all the resources acquired
using var file = new System.IO.StreamWriter(fileName);
{
file.Write(s);
} // <- here the resources will be released
}
In case of C# 8.0 you can get rid of pesky {...} and let the system release resources on leaving method's scope (see https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8#using-declarations):
public static void WriteStringToFile(string s, string fileName)
{
// Let system release all the resources acquired
using var file = new System.IO.StreamWriter(fileName);
file.Write(s);
} // <- here the resources will be released
Rookie here so please be nice!! I have had so much fun learning to program and gotten some great help along the way when google failed me. But alas, I'm stuck again.
I have a C# program that looks like this (It's MWS if anyone is familiar)
I've tried so many different ways to get this to effectively loop through a list of values in a text file. The problem I'm having is that the Main function is where I have to set the loop, but the BuildClass is where I need to cycle through the values in the text file (sentinel). I've included some stuff that probably isn't necessary just in case it is messing my code up and I don't realize it.
Here's what I've tried:
setting the loop inside the BuildClass - didn't expect it to work but it threw an exception before getting to the sentinel.
Reference the sentinel within the main function by changing the "using" or "var" in the main function sentinel to public - turned EVERYTHING red in visual studio
moving the string sentinel outside the main function so that the function and the BuildClass would recognize it - main function did not recognize it anymore.
I've tried so many other things unsuccessfully. I've gotten it to loop with the same sentinel value passed from BuildClass to the function over and over again but that's about it.
What I think I need:
A destructive version of streamReader that will remove the value from the text file when reading it. I'll put this inside the BuildClass, so that the next loop of the main function, the next value will be read and passed into the main function until the file is empty, terminating the loop.
an understanding of why changing sentinel to public destroys the code so badly. I have a decent understanding of why the other attempts wouldn't work.
namespace MainSpace
{
public class MainClass
{
int i;
public static void Main(string[] args)
{
ClientClass client = new ClientInterface(appName, appVersion, password, config);
MainClass sample = new MainClass(client);
string sentinel;
using (var streamReader = new StreamReader(#"sample.txt", true))
while((sentinel = streamReader.ReadLine()) != null)
{
try
{
//stuff
response = sample.InvokeBuild();
Console.WriteLine("Response Stuff");
string responseXml = response.ToXML();
Console.WriteLine(responseXml);
StreamWriter FileWrite = new StreamWriter("FileTest.xml", true);
FileWrite.WriteLine(responseXml);
FileWrite.Close();
}
catch (ExceptionsClass)
{
// Exception stuff
throw ex;
}
}
}
private readonly ClientInterface client;
public MainClass(ClientInterface client)
{
this.client = client;
}
public BuildClass InvokeBuild()
{
{
using (var streamReader = new StreamReader("sample.txt", true))
{
string sentinel = streamReader.ReadLine();
Thread.Sleep(6000);
i++;
Console.WriteLine("attempt " + i);
// Create a request.
RequestClass request = new RequestClass();
//Password Stuff
request.IdType = idType;
IdListType idList = new IdListType();
idList.Id.Add(sentinel);
request.IdList = idList;
return this.client.RequestClass(request);
}
}
}
}
We have a confusing case, where code that runs normally hundreds of times suddenly stopped working. It is an application that usually runs for weeks.
The question is, do XmlSerializer(Type) have some cache somewhere, which can be corrupted?
The background:
It happened at startup, at one occasion, that we got a lot of exceptions. After a restart when the problem was detected (a few days later), it ran normally again.
We have tracked down the problem to this code:
internal static class StateManager
{
private static XmlSerializer queueSerializer = new XmlSerializer(typeof(List<QueueItem>));
private static readonly string queuePath = Path.Combine(SubSystem.PersistentDirectory, "Queue.xml");
internal static void SaveQueue(List<QueueItem> upcomingTasks)
{
XmlWriter xmlWriter = XmlWriter.Create(queuePath, xmlSettings);
queueSerializer.Serialize(xmlWriter, upcomingTasks);
xmlWriter.Close();
}
internal static List<QueueItem> GetQueue()
{
var queue = new List<QueueItem>();
try
{
var xmlDoc = new XmlDocument();
xmlDoc.Load(queuePath);
using (XmlReader reader = XmlReader.Create(new StringReader(xmlDoc.OuterXml)))
{
queue = queueSerializer.Deserialize(reader) as List<QueueItem>;
}
}
catch (Exception e)
{
AppTrace.Write(TraceLevel.Error, string.Format("Failed to load State Queue: {0}", e.Message));
}
return queue;
}
}
and the error we get is:
Failed to load State Queue: The type initializer for 'StateManager' threw an exception.
As we understand it, this leaves two possibilities for the culprit:
private static XmlSerializer queueSerializer = new XmlSerializer(typeof(List<QueueItem>));
or
private static readonly string queuePath = Path.Combine(SubSystem.PersistentDirectory, "Queue.xml");
We have checked SubSystem.PersistentDirectory carefully, and believe it to be innocent.
Since this happened in the field at a client's machine, and we cannot reproduce it, checking the inner exception is not possible.
You should catch that ! I see there is no static ctor there, you might attempt something like this, deferring initialization so you're able to know more:
internal static class StateManager
{
private static XmlSerializer queueSerializer;
private static readonly string queuePath;
internal static StateManager(){
try
{
queueSerializer = new XmlSerializer(typeof(List<QueueItem>));
queuePath = Path.Combine(SubSystem.PersistentDirectory, "Queue.xml");
}
catch(Exception ex)
{
// Log, log, log!
throw; // Essential: you MUST rethrow!
}
}
}
As far as the actual offending line, there is no way to tell for sure without a trace: all you know is that your type could not be initialized, with no indications about the why.
The most likely causes, as far as I can guess, are:
Something is broken in the data you feed to the XmlSerializer (not the XmlSerializer itself: I highly doubt that anything coming from the System namespace is prone to blowing up at random)
Your SubSystem.PersistentDirectory contains broken data
(Unlikely, but you never know...) Something else is broken and the exception is not actually related to the offending code, which might reside elsewhere
I'm VERY new to C# so please allow me some ignorance :)
(I've tried searching around to understand the reason for the difference in performance I'm seeing but as of yet don't have a definitive answer so I thought I'd ask the knowledgable audience on here...)
Basically... if I use streamwriter something like:
public static class Logging
{
readonly static object DebugWriter = new object();
public static void Log(string msg)
{
lock (DebugWriter)
{
using (StreamWriter writer = new StreamWriter("Debug.txt", true))
{
writer.WriteLine(DateTime.UtcNow.ToString("HH:mm:ss.ffff") + " " + msg);
}
}
}
}
then assuming I send a large amount of text out via this class I see a noticeable hit on CPU.
However if I instead write it something along the lines of:
public static class Logging
{
readonly static object DebugWriter = new object();
static StreamWriter lwriter = new StreamWriter("LocalDrivenDebug.txt", true) { AutoFlush = true };
public static void Log(string msg)
{
lock (DebugWriter)
{
lwriter.WriteLine(DateTime.UtcNow.ToString("HH:mm:ss.ffff") + " " + msg);
}
}
}
Then I see pretty much no hit on the CPU at all.
Is the above caning the CPU purely through inialisation and disposal caused by the using statement? (If so what the hell is C# doing to eat so much CPU???) - Given it's a static class and I've forced autoflush, surely the same applies to the second version or does its disposal get acted on differently and hence chew up less CPU time?
I can only assume I'm missing something obvious. So hopefully someone out there can enlighten me as I 'thought' you were supposed to use the using statement as a safer/more convenient way of doing the disposal?
The second snippet has two properties :
- It doesn't recreate the writer, which can help if you call log many times.
- It doesn't dispose the writer, which means the text you are writing is not flushed to disk yet, but rather kept in memory for later flushing ! On the other end, you write on disk every call to log with the first snippet.
All in all, these two effects should explain the noticeable difference you see :)
I'm a C# programmer.
Now, I'm using the ICSharpCode.SharpZipLib.dll to create a zip file in my current project. But it occurs to me that when I click the button at the SECOND TIME to execute a function to create a zip file, the application will throw an exception, friendly and seriously told me that "Size was zero, but I expected 46086".
I'm so confused that I want to know why? When I click the button at the first time, I can do it successfully without any error.
My related codes are as follows:
internal void ThreadProc()
{
try
{
ZipHelper.CreateZip(backupZipFile, Constants.HomeConstant, true);
// do other things
}
}
The CreateZip() function's realization is as follows:
public static void CreateZip(string zipFileName, string sourceDirectory, bool recurse)
{
FastZip zip = new FastZip();
if (File.Exists(zipFileName))
{
File.Delete(zipFileName);
}
zip.CreateZip(zipFileName, sourceDirectory, true, "");
}
Now, I will show you the recursive calling process:
Call method "UpdateAppAsync" in "ActiveCheckManager" class
public void UpdateAppAsync(string masterConfig)
{
this.masterConf = masterConfig;
Thread actualThread = new Thread(new ThreadStart(UpdateApp));
actualThread.IsBackground = true;
actualThread.CurrentCulture = Thread.CurrentThread.CurrentCulture;
actualThread.CurrentUICulture = Thread.CurrentThread.CurrentUICulture;
actualThread.Start();
}
Call the UpdateApp function asynchronously, in the UpdateApp method, it will only call the UpdateDetail function simply.
private void UpdateDetail(string masterConfig, string category)
{
IUpdate worker = new HP.ActiveCheckLocalMode.UpdateEngine.UpdateManager();
worker.UpdateApp(masterConf);
}
The worker.UpdateApp will call UpdateDetail(string, UpdateCategory) only.
private void UpdateDetail(string masterConfig, UpdateCategory cat)
{
UpdateThread updateThread = new UpdateThread(this, cat);
updateThread.MasterConfig = masterConfig;
updateThread.ThreadProc();
}
That is the calling process. When I click the update button second time, it will throw an exception, can you help me? Thank you very much.
Has the first task thread finished before you start the second time?
I would imagine that File.Delete() and some items in the SharpZipLib to not respond nicelly to multithreadingly zip the same folder simultaneously to the same file.
Promote that " UpdateThread updateThread " as a private member of the "ActiveCheckManager" class, then check if it is already running from a previous click before creating a new thread.