|
Thank you for the reply.
I read the parameters from a text file that is why I need to determine the type of the parameter from the string programmatically.
I am a SysAdmin, I battle my own daemons.
|
|
|
|
|
Use the Enum.Parse method to parse the string into an enum value.
---
single minded; short sighted; long gone;
|
|
|
|
|
Mark Greenwood wrote: you'll have to have a switch statement to select the correct database type from the string passed in
Or you could just use Enum.Parse
|
|
|
|
|
you all suggested to use enum.parse must be the way to go although i can't try it right now (no compiler).
anyhow, the problem above is similar to the following simplified version:
if( strType == "int" )
{
//instantiate an int i.e.
Add(varInt, int, 10);
}
thanks for the help... hope enum.parse is what i am looking for.
I am a SysAdmin, I battle my own daemons.
|
|
|
|
|
Is it a good idea to have my Data Access Layer on Web Service?
What I mean is, All communication of different tier with the underlying database must all be done using XML web sevices.
What are the Cons and Pros of my idea?
Thanks in Advance.
|
|
|
|
|
Hey,
Select a suitable forum for posting your question. Dont post it in different forums. Becoz i have seen the Same Question in Asp.Net forum and also in Sql/Ado/Ado.Net Forum Also.
Regards,
Satips.
|
|
|
|
|
Hii All,
I have a problem to compile C# project to *.dll file. everytime I compile, always display
"WEBAGIS_DLL.exe' does not contain a static 'Main' method suitable for an entry point"
and if I run with a normal c# code that make *.exe.
can somebody help me to give some sample how to create dll file use c# at Visual NET 2005 project?
Thanks a lot
Regards
Albert04
study
|
|
|
|
|
Start with a class library project, not a Windows, or Console application.
only two letters away from being an asset
|
|
|
|
|
ooh yeah...thanks a lot. I start with windows application. you right, start with a class library
Regards
Agus
study
|
|
|
|
|
I - as a user - am running a daemon that I want to provide some service to other applications that I am running. Some of my applications are also using a library that interfaces with this daemon.
Currently I'm using WCF via named pipes so all the plumbing is taken care of for me, but this solution seems to fall apart whenever another user logs onto the machine and also tries to start this daemon. Is there any way for both of our services to co-exist peacefully?
Specifically, how can I allow multiple users to run a daemon concurrently (limited to one daemon per user) while
- ensuring that a library running under user A's account will try to connect *only* to the daemon also running under user A's account, and
- ensuring that the daemon running under user A's account will allow connections *only* from applications running under user A's account.
I was thinking of creating a uniquely named pipe that derives from the user's SID, but this seems more like a hack than a solution and I think it would be quite fragile. I also wouldn't know how to limit connections to only the current user.
If I'm going about this in the wrong way, that would also be nice to know.
Thanks for any insight you guys and gals are able to provide! 
|
|
|
|
|
Windows services are per-machine, not per-user. One way to accomplish what you are doing is to have a service that does all of the work and then a client-side piece that communicates to the service. The client piece runs per-user and is what the user would interact with, but it wouldn't be a service. It could be a task-tray application (one that only runs in the system notification area).
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Scott Dorman wrote: Windows services are per-machine, not per-user.
Right. I was considering just adding a daemon executable to the Startup path of whichever user installed the application.
Scott Dorman wrote: One way to accomplish what you are doing is to have a service that does all of the work and then a client-side piece that communicates to the service.
Ideally the user could install and run this application without requiring administrator privileges. Also, I want to minimize as much as possible the possibility of cross-communication between clients and daemons running under different user accounts.
In reality what I have going on is that the client is performing all the work. The client just needs to query the daemon for some state before work can commence, and it needs to tell the daemon how to update the state when the work is complete. When the next client queries the state, the daemon can respond with the updated information.
The problem with a system-wide service is that the daemon can be used quite broadly, and the client might update the state with some private information. If the daemon is used as a day planner, for example, the client might add a personal appointment to the database. This isn't information that should be accessible to any other user of the system.
Hopefully this clarified things a bit. Again, thanks for your insight! 
|
|
|
|
|
Vega02 wrote: I was considering just adding a daemon executable to the Startup path of whichever user installed the application.
Yes, that would be a good approach.
Vega02 wrote: Ideally the user could install and run this application without requiring administrator privileges. Also, I want to minimize as much as possible the possibility of cross-communication between clients and daemons running under different user accounts.
Running the client piece without admin privs should be relatively simple. Installing without them might cause an issue on Vista.
Vega02 wrote: In reality what I have going on is that the client is performing all the work. The client just needs to query the daemon for some state before work can commence, and it needs to tell the daemon how to update the state when the work is complete. When the next client queries the state, the daemon can respond with the updated information.
It sounds like the service is really just being used as state management.
Vega02 wrote: The problem with a system-wide service is that the daemon can be used quite broadly, and the client might update the state with some private information. If the daemon is used as a day planner, for example, the client might add a personal appointment to the database. This isn't information that should be accessible to any other user of the system.
I'm not sure why this would be an issue. If the service is designed right and provides some sort of authentication mechanism between itself and it's clients, client A should never be able to see data from client B. Given the scenario you described, the underlying data store would need to be protected as well.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Howdy
I've recently converted from Java to .NET and I'm having problems with exceptions. The process for catching and handling exceptions in C# is identical to Java, no problem there. My problem lies in discovering the possible exceptions thrown by methods.
In Java the method signature explicitly declares whether a method throws a exception (or exceptions). This does not seem the case with C#. When viewing the class MSDN I cannot seem to find documentation about the exceptions a method might throw.
The only information I can get is sometime the intelli sense displays a list of exceptions, but this doesn't seem comprehensive.
Is there documentation about what exceptions are thrown by method or a way to find out possible exceptions thrown.
Thanks heaps for any help.
Cheers
Q
|
|
|
|
|
Here is a blog I use from time to time
Brad Abrams blog
try
{
screwed up stuff
}
catch(ArgumentException ex)
{stuff catcher}
catch(PathTooLongException ex)
{more stuff}
catch(Exception ex)
(the catch all stuff)
finally
{This always gets hit}
|
|
|
|
|
Thanks for you reply
I have good understanding of how to catch and deal with exceptions. What I'm looking for is what type of exceptions are thrown.
I might not have been clear enough. I'm basically looking for class documentation that explicitly declares what exceptions are thrown - Similar to the Java API.
Cheers
|
|
|
|
|
Quinten.Miller wrote: I'm basically looking for class documentation that explicitly declares what exceptions are thrown - Similar to the Java API.
.NET Class Library[^]
Each method is documented with the types of exceptions it throws. For example, the documentation for the Random class's Next(int maxValue)[^] method states that it will throw an ArgumentOutOfRangeException if maxValue is less than zero.
|
|
|
|
|
Hi Leslie
The .NET Class Library is what I'm looking for. I guess I will have to get use to the different way of dealing with code that causes exceptions.
Thanks heaps for you help
Cheers
Q
|
|
|
|
|
You could use reflection to view the methods. You can also catch Exception, which catches all. You should avoid this. Generally, the exceptions will be obvious ( FileNotFound for a delete method, for example ).
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Other than looking at the documentation (and trusting that it has been fully documented) there aren't any tools (at least none that I'm aware of) that will generate a list of exceptions.
It would be possible using a tool like Reflector[^], but that would be a very manual process.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Visual Studio 2003 has this problem. However, Visual Studio 2005 does list the exceptions for the method call. Just hover your mouse over the method name for a moment.
Phil
|
|
|
|
|
Cheers
Looks like VS2005 is the way to go
Thanks for this info
|
|
|
|
|
 Hi
I think you can solve your problem as below:
Put All the statements of your method in a Try-Catch.
for example:
private void divisionOperator()
{
try
{
result = result / x ;
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
Nima_e
|
|
|
|
|
Thanks for your reply
Not really a good idea to use a catch all exception if you don't have to. Better in this case to use a NumberFormatException (from memory). Catching a plain exception can cause other problems like hiding an exception that you might not have thought possible to throw.
For better explanation have a read of this article: Exception Handling Best Practices in .NET[^]
Cheers
Q
|
|
|
|
|
I think it's a shame that checked exceptions weren't implemented in c#. I love them.
Here's a link that discusses why they were left out of c#
http://www.artima.com/intv/handcuffs.html
HTH
Russell
-- modified at 8:26 Wednesday 11th April, 2007
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
