|
Can any one help
How to create the Setup file in C# Console Application in .Net
|
|
|
|
|
bruze wrote: How to create the Setup file in C# Console Application in .Net
Not sure what you want to know. You add one to the project using the menu "Add Item"
led mike
|
|
|
|
|
Do you mean setup file which will install your console application to PC?
- Stop thinking in terms of limitations and start thinking in terms of possibilities -
|
|
|
|
|
How to create the executable file in c# console application in .net
|
|
|
|
|
bruze wrote: How to create the executable file in c# console application
The Executable is already created as soon as you compile your code. You can find the executable of your C# Console Application in Bin -> Debug folder of your project.
- Stop thinking in terms of limitations and start thinking in terms of possibilities -
|
|
|
|
|
|
I'd like to have a globals class in my app with a global dictionary, but am having trouble getting past the error below. Any ideas or suggestions?
<br />
using System;<br />
using System.Collections.Generic;<br />
namespace GlobalDict<br />
{<br />
public partial class Globals<br />
{<br />
public static Dictionary<string, int> GlobalInts = new Dictionary<string, int>()<br />
{<br />
{"one", 1},<br />
{"two", 2},<br />
};<br />
}<br />
class Program<br />
{<br />
public static Globals g = new Globals();<br />
static void Main(string[] args)<br />
{<br />
int i = g.GlobalInts["two"];<br />
<br />
}<br />
}<br />
}<br />
Sincerely,
-Ron
|
|
|
|
|
Aside from warning you about using globals AND public members, you can't use an instance. Try this syntax: Globals.GlobalInts["two"]; If you remove the static modifier, you'll be able to use the instance reference.
Scott P
“It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.”
-Edsger Dijkstra
|
|
|
|
|
Lets say i however fire the Close method.and close it is fine. but i want to confirmed it is actually close and dispose with that resources.
Because i have a page and i have used a TVgrabber componenet and show TV card tuner, but when i going to another page closing that..it gets flicker with my page. I couldn't close that Grabber properly also i want to dispose all in.
using System;
using System.Data;
using System.Data.SqlClient;
using System.Collections;
namespace ItvC
{
public partial class frmTVX : Form
{
public static frmTVX tv = null;
public frmTVX()
{
InitializeComponent();
tv = this;
}
private void Close()
{
this.TopMost = false;
this.Close();
frmMain.FormMain.Show();
}
}
}
|
|
|
|
|
Well...
First, you're calling Close() from within itself. Eventually, you're gonna run out of stack space.
Second, the last line in Close() will never be executed because you're recursing back to the same function before it gets there.
I'm surprised your system hasn't caught fire yet as a result.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
i have created the service project and sometimes it gives some exceptions. i want to handle them and show the message to the user by MessageBox . but in this context there is no MessageBox . How can i use the MessageBox?
|
|
|
|
|
It's generally not a good idea to have a service interact with the user.
If you really know what you are doing, you have to add a reference to System.Windows.Forms to show a MessageBox. For it to actually appear, ensure the checkbox for Allow service to interact with desktop is checked (service applet - properties).
How about logging the events, or sending out an email when something fails?
Cheers,
Vikram.
The hands that help are holier than the lips that pray.
|
|
|
|
|
|
You can't/shouldn't.
Instead, write an system tray application that monitors the service and puts the message box up itself...
[EDIT] Why did you vote this a one? Did you want me to write the code for you too?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
modified on Wednesday, May 14, 2008 3:31 PM
|
|
|
|
|
It wasn't the OP who 1-voted you, it was someone with gold status. He(?)'s bronze, so if it was him the average with my 5 would've been 4.2, not 3.
You know, every time I tried to win a bar-bet about being able to count to 1000 using my fingers I always got punched out when I reached 4....
-- El Corazon
|
|
|
|
|
With a service it's a very bad idea to assume there is a user at all. Services are by definition assumed to have no user present, supervising them. Often services are running on a remote computer like a file or application server that may be in another country from the person responsible for it.
Keep this in mind at all times when writing a service, it should handle everything possible on it's own.
Have a look at the System.Diagnostics.EventLog component. That is a commonly expected and accepted way for a service to indicate an error of some kind. Avoid the temptation to put too much in that log, your users won't appreciate it. Stick to truly important messages.
Then users can view a problem in the Event log in windows if they have one or use many automated tools for working with the event log (like emailing them if an error occurs etc etc).
"The great pleasure in life is doing what people say you cannot do."
- Walter Bagehot
|
|
|
|
|
thanks. I got another problem with service project.that is when i install it after restarting the machine service is running, but the name of the exe file which installed is displayed in ADD/Remove Prog's. through it can be uninstalled. is it ok to display it in ADD/Rem Prog's.
|
|
|
|
|
Very bad practice to start a new question in an existing thread. Start a new thread if you have a new question please.
"The great pleasure in life is doing what people say you cannot do."
- Walter Bagehot
|
|
|
|
|
Hello everyone,
Here is my code for Dispose method. Currently, I am thinking whether it is necessary to make it thread safe by adding a lock to prevent two threads to execute Dispose methods at the same time?
Notes:
1. disposing is used to indicate explicit call to Dispose or implicit call from Finalizer;
2. disposed is used to indicate whether current instance is Disposed or not, to prevent from disposing again. The thread safety consideration is used to protect this variable.
protected virtual void Dispose(bool disposing)
{
lock (DisposeLock)
{
if ((false == disposed) && (true == disposing))
{
disposed = true;
}
}
}
thanks in advance,
George
|
|
|
|
|
Why would two threads call dispose on the same object ?
Christian Graus
Please read this if you don't understand the answer I've given you
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Thanks Christian,
My concern is, if a reference is or potentially held by two threads, and they may call Dispose at the same time. Any comments?
regards,
George
|
|
|
|
|
They may not. Strictly speaking, if two threads or objects hold references to a single object, neither of them may call Dispose.
If they do, they are violating the fundamental rules of the IDisposable pattern.
The rules in short:
1. Dispose is meant to tell an object this: "I now know for sure that nobody has a reference to you except for myself, and I will never talk to you again - you may now safely throw away any resources you've been holding on to. If I or someone else ever talks to you again, please throw an exception.".
2. If you don't know for sure that you're the only one holding a reference to the object, you should never call Dispose. Just drop your reference (as in myRef = null;). The GC (garbage collector) will then call its finalizer (~TheClass) as soon as a) it realizes that nobody holds a reference to the object any more and b) it or your program has nothing more important to do. The finalizer will call Dispose(false), ensuring that any unmanaged (operating system handles and whatnot) will finally be released.
The only reason that the docs say that you should always allow calls to Dispose even if you are already disposed or not completely initialized is that you may in some cases get called from a catch or finally block that shouldn't have to check whether or not the try block that should have called you actually did it before the exception got thrown. This can never occur simultaneously on different threads, though.
So, the IDisposable stuff is only an optimization, enabling us to force expensive resources to be released before the GC gets around to it - but it should never be used unless we know for sure that the object is dead for good. Note that there is a lot of code (even in the framework) that just crashes spectacularly instead of throwing the proper exceptions if you try to use an object that has been disposed. Try loading a bitmap, showing it in a picture box and then disposing it (while still showing it). Results will vary - the app may exit silently, throw a protection fault or even display random graphics. At least, this was true in 1.1 - it was a while since I tested that.
Later,
--
Peter
|
|
|
|
|
Great reply, Peter!
1.
PeterTheSwede wrote: The only reason that the docs say that you should always allow calls to Dispose even if you are already disposed or not completely initialized is that you may in some cases get called from a catch or finally block that shouldn't have to check whether or not the try block that should have called you actually did it before the exception got thrown. This can never occur simultaneously on different threads, though.
I am very interested in the scenario you described, but still confused after reading a couple of times. Could you show some pseudo code please?
2.
"dead for good" means on one else refers the object?
3.
PeterTheSwede wrote: Note that there is a lot of code (even in the framework) that just crashes spectacularly instead of throwing the proper exceptions if you try to use an object that has been disposed.
You mean ObjectDisposedException should be thrown -- and in your points should be the correct behavior -- in this scenario?
regards,
George
|
|
|
|
|
1. I'll try.
If I remember the recommendations for the IDisposable interface correctly, the requirement that duplicate (but not simultaneous, mind you) calls to Dispose() shouldn't fail is explained with something like this:
MyClass obj = new MyClass();
try
{
obj.DoSomethingThatCanFail();
obj.Dispose();
this.DoSomeOtherStuff();
}
catch
{
obj.Dispose();
throw;
}
This code should be considered correct - that is, you shouldn't have to check if things went wrong at A or B in the catch block. Note that obj could potentially be a 2GB image, and the DoSomeOtherStuff() method could also be something extremely memory-hungry. In which case it makes sense to call obj.Dispose() then and there instead of in a finally block.
2. Exactly.
No one but you refers to it and you aren't ever going to use it again. If you can't guarantee those conditions, you're essentially not allowed to Dispose() the object.
3. Yes.
According to Microsofts current recommendations, ObjectDisposedException should be thrown if you try to do anything with an object that is disposed (except calling Dispose() again). But like I said, there's a lot of code out there that just crashes instead. Understandably - it's easy to forget if (disposed) throw new ObjectDisposedException(); in a method or property somewhere.
Which makes it even more important to never use Dispose() unless you're absolutely sure that the object is dead. People who get buried alive don't play nice... 
Later,
--
Peter
|
|
|
|
|
Thanks Peter,
Your reply is great!
1.
In your sample, it is possble to call Dispose twice on the same object if there is exception thrown from DoSomeOtherStuff, in this case, there will be ObjectDisposedException from catch block?
2.
Is it always a program bug when we met with ObjectDisposedException? Means someone Disposed the object instance, but some other guys may still refer it and call the method on it.
3.
I like your below code,
if (disposed) throw new ObjectDisposedException();
Currently, I think of two solutions when met with ObjectDisposedException. Solution 1 is to do operations on object straigtforward without checking IsDisposed property, and wrap catch block to catch ObjectDisposedException, solution 2 is to check IsDisposed property as you showed above, and it is set, do nothing but throw ObjectDisposedException to propogate out or write a log without rethrow. I am wondering which pros and cons and your suggestions of which solution is better?
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
