|
It is. Thanks for the advice I'll check it out.
|
|
|
|
|
how to create a export xml file in SQL database using c# tnx..
|
|
|
|
|
There are a huge number of ways!
The easiest is to use a DataSet.
Easy write:
Create your data in a DataTable, then:
DataSet ds = new DataSet();
ds.Tables.Add(dt);
ds.WriteXml(@"D:\Temp\td.xml");
Easy Read:
DataSet ds = new DataSet();
ds.ReadXml(@"D:\Temp\td.xml");
dt = ds.Tables[0];
You can use DataTable.ReadXml instead, but it doesn't support schema inference, DataSet.ReadXml does.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Hi everyone,
My application was written in Visual Studio 2010.
After closing my application, there is still a running process that showed in the Task Manager.
Do you know, how to dispose all resources after I close my C# application ?
Thanks and regards,
Tai
|
|
|
|
|
taibc wrote: After closing my application, there is still a running process that showed in
the Task Manager. Do you know, how to dispose all resources after
I close my C# application ?
All .NET objects will be disposed of by the runtime. Did you launch a (non-background) thread?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Yes.
I found out a way to do that by use the statement:
Process.GetCurrentProcess().Kill();
Thanks and kind regards,
|
|
|
|
|
taibc wrote: Process.GetCurrentProcess().Kill();
Yep.... that will work.... if you do not want to do it correctly.
|
|
|
|
|
Actually, that'll leak resources, not close them.
|
|
|
|
|
Dave Kreskowiak wrote: Actually, that'll leak resources, not close them.
What resource do you think will be leaked after the Process exits?
|
|
|
|
|
Off the top of my head, anything that holds an unmanaged handle, such as GDI objects: Brush, Pen, Graphics, ...
That's by no means a complete list of the stuff that can be orphaned, just a sample.
|
|
|
|
|
I doubt that a Process will hold on to any of those when the Process exits, regardless of how it exits.
|
|
|
|
|
I wouldn't bet on that - from experience.
|
|
|
|
|
|
Maybe not. It may depend on if you run the system out of resources first. My experience was killing a process that leaked handles like crazy. Once you exhaust the handle pool, Windows starts to loose it's mind.
|
|
|
|
|
Dave Kreskowiak wrote: Windows starts to loose it's mind.
Which version of windows?
|
|
|
|
|
|
taibc wrote: I found out a way to do that by use the statement:Process.GetCurrentProcess().Kill();
There's no book that recommend thus. It might "feel" as a fast way to exit the app, but as you noticed, it doesn't exit nicely.
You might wanna research the difference between foreground and background-threads. I'll bet one of them is still running.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
taibc wrote: Do you know, how to dispose all resources after I close my C# application ?
Wrong question.
Presumably your application only has one process - if not then you must have started the other processes so stopping them is also required.
But excluding that then if your application (process) is still running after you "close" it then that means you started a thread that continues to run. So the solution is that when you "close" it that you must terminate the threads that you started.
And the terminology is not apt since it isn't a matter of "resources" - it is an application/process which has not terminated. Once the process terminates all of the resources are freed regardless of the action your application took.
|
|
|
|
|
Hello Everybody,
i am struck with a project where i have to pass a message from pc to micro controller device (Ethernet to serial converter interfaced to micro controller).
cable which i use is straight pair. Ethernet serial converter has a ip address. using this ip address i need to trasfer the message. port number i am using is 23.
the microcontroller works fine because we have tested it in hyperterminal(os-windows 7) and microcontroller is able to sends & receive the messge and in hyperterminal it sends & recieve succcesfully .
i used the following code (windows application, c# language, .Net Framework 4.0) to implement it. but it is not working. can i get any sugession or sample code where i will know what is the mistake
private void Form_Load(object sender, EventArgs e)
{
try
{
// Check the port value
if (textBoxPort.Text == "")
{
MessageBox.Show("Please enter a Port Number");
return;
}
string portStr = "23";
int port = System.Convert.ToInt32(portStr);
// Create the listening socket...
m_mainSocket = new Socket(AddressFamily.InterNetwork,
SocketType.Stream,
ProtocolType.Tcp);
IPAddress address = IPAddress.Parse("192.168.0.50");
IPEndPoint ipLocal = new IPEndPoint(address, port);
// Bind to local IP Address...
m_mainSocket.Bind(ipLocal);
// Start listening...
m_mainSocket.Listen(4);
// Create the call back for any client connections...
m_mainSocket.BeginAccept(new AsyncCallback(OnClientConnect), null);
UpdateControls(true);
}
catch (SocketException se)
{
MessageBox.Show(se.Message);
}
}
|
|
|
|
|
Did you try the other direction? Like from this app going into another PC running hyperterminal through your ethernet/serial adapter?
|
|
|
|
|
After creating a lot of objects and then freeing them in my code and calling GC.Collect(2) the memory footprint does not go back to the pre allocation point in the app.
Using a tool called VMMap (great tool by the way!) it show that the memory is in the GC's hands (out of the application's).
Is there a way to get around this?
A programmer walks into a bar and asks the bartender for 1.00000000000003123939 root beers. Bartender says, I'll have to charge you extra, that's a root beer float. Programmer says, better make it a double then.
|
|
|
|
|
I think it is implementation-specific. The VM doesn't explicitly call free() on those objects. Instead, it caches the memory for further reuse in order to cope with malloc() overheads. But, if I leave my app idle for a while, the memory is slowly released. Same thing is also observed in Oracle's Java VM for windows.
Beauty cannot be defined by abscissas and ordinates; neither are circles and ellipses created by their geometrical formulas.
Source
|
|
|
|
|
Task Manager is showing you the memory the the .NET CLR has RESERVED for your application, not how much it's actually using. The same goes for VMMAP. Neither tool goes into any of the details of the managed runtime memory manager.
If you want to see how much memory your app is really using at any point in time, open PerfMon and use the .NET Memory counters in there.
The memory that your application uses, when freed, gets returned to the Managed Heap in the .NET CLR, not to Windows. This is because allocations for future objects are faster is there is memory available in the managed heap. If not, then a block of memory has to be allocated from Windows, put in the managed heap, then your object allocated. This takes more time.
Unless you're really worried about how much memory your app is actually using, you're worried about nothing. The .NET CLR memory manager is very good at it's job and tunes itself depending on how your app is running. It's constantly watching how your app allocates and frees memory and adjusts the size of the managed heap every once in a while. But, if Windows needs the memory back, the .NET CLR will happily return any memory it can to Windows.
|
|
|
|
|
Thanks Dave!
The problem was in RaptorDB when I was inserting 100K docs into it which uses around 600Mb of ram, this was fixed by freeing internal cache data after saving to disk which brought it back down to around 150Mb, however restarting the app with the same data files only uses 70Mb and works like a charm, so I was perplexed where the difference was since I released all my cached data.
Anyway the problem of memory usage is fixed but I still get a nagging feeling about the difference.
A programmer walks into a bar and asks the bartender for 1.00000000000003123939 root beers. Bartender says, I'll have to charge you extra, that's a root beer float. Programmer says, better make it a double then.
|
|
|
|
|
That "diamond reply," imho, Dave, deserves to be enshrined in a Tip-Trick.
yours, Bill
~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
|
|
|
|