|
I have the need to build a client-server system. It will all be working on an intranet, distributed on multiple PCs.
One will be a server application, hosted on a PC, that will manage the data.
The second will be a client application. It will be used to read and modify the data. This application already exists, for the most, and is a C++ application. It is huge so it cannot be done from scratch again. I have seen that I can expose a COM interface from .Net, so I will probably do a library that will be used as an interface between my old C++ app and the .Net architecture.
I also need the server to be able to send notifications to the client applications when some changes occurs, so I need a subscription mechanism.
I am relatively new to .Net so I am not sure what the best technology is.
I have looked at WCF, but it does not seem ideal for the subscription/notification part. Am I wrong?
What else is there that could be better?
|
|
|
|
|
Instead of the COM dll you might consider using managed C++ for the old app. This will let you mix both managed (.NET) and unmanaged code in the same files and will give you all of the .NET stuff you might want.
The other stuff, someone else might have to comment on.
I use c# for my client server apps but I use straight sockets for my information.
|
|
|
|
|
Thanks for the suggestion.
I forgot to mention that the C++ app is still running in VC6, and unfortunately there is no plan to migrate it yet. So C++/CLI is out of the picture, though I had a look at it. Such a shame...
|
|
|
|
|
I cannot tell you if WCF would be ideal for subscription/notification part, I don't know, but it can be done with WCF. You can find an example here[^] about WCF callbacks.
|
|
|
|
|
Thanks, I will have a look at that.
|
|
|
|
|
I have an application which is using an image which is picked up from a resource file.
i have this exception-
"Could not find any resources appropriate for the specified culture or the neutral culture. Make sure \"WindowAplication1.Properties.Resources.resources\" was correctly embedded or linked into assembly \"WindowApplication1\" at compile time, or that all the satellite assemblies required are loadable and fully signed."}
How can I handle this???
Thanks in adv...
|
|
|
|
|
The clues are in the question:
1) Make sure "WindowAplication1.Properties.Resources.resources" was correctly embedded or linked into assembly "WindowApplication1" at compile time
2) All the satellite assemblies required are loadable and fully signed.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Dear All --
Forgive me if I am being greedy. Upon writing a function header say "Private void FntName()" is there a way the two curly braces and the try catch block is automatically inserted. 
cheers
|
|
|
|
|
If you're using VS I guess this could be done by creating code snippets.
|
|
|
|
|
Calla --
Yup I am using VS 2005. But I want it automated. How will I trigger it ?
cheers
|
|
|
|
|
You may wish to ask yourself why you want to insert a try-catch into every method you are creating. That is no way to trap errors properly. It will just make the entire application nearly impossible to effectively debug the application.
If you do wish to do it, look up on how to creating studio add-ins. You may want to tie in that way to automate the process with no user intervention(i.e. keystrokes), but the logical way would be to create a snippet, and assign a keystroke to it so that you only have to type that to get the whole block inserted.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
I'm with PogoboyKramer on this - try catch round each and every method just look like you are saying "I don't know what I am doing, so I'll try and ignore as many problems as I can instead of fixing the problems behind them"
Smacks to me of VB's "On Error Resume Next" 
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
OriginalGriff wrote: On Error Resume Next
Goto Happyland
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
PogoboyKramer wrote: Goto VeryUnHappyland if you are the poor sod maintaining it...
FTFY! 
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Reading between the lines... You've worked with BA's before
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Who hasn't?
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
If you like removing said Try/Catch blocks all the time, this would be a good idea. But, it's a horrible idea to put a try/catch block in every method. You're not really doing/handling exceptions properly if this is the case, but instead making a nightmare of debugging your app.
|
|
|
|
|
Dave --
Tell me one instance where you wouldn't prefer placing a try/catch in a method.
cheers
|
|
|
|
|
thomforum wrote: Tell me one instance where you wouldn't prefer placing a try/catch in a method.
Two instances. There are many others.
public int Count
{
get { return count; }
set
{
if (value >= 0)
count = value;
}
}
private int count;
public void Initialize(String name)
{
if (String.IsNullOrEmpty(name))
throw new ArgumentException("Name must be defined");
this.name = name;
}
I also do not want to see the following. The following might require try/catch somewhere but logging the exception twice does nothing but provide confusion. So the question becomes what does the one try/catch do that the other does not?
private void ProcessTxn()
{
try
{
...
}
catch(Exception e)
{
__log.Error("Failed to process txn", e);
throw;
}
}
public void Process()
{
try
{
PrepareTxn();
ProcessTxn();
SaveTxn();
}
catch(Exception e)
{
__log.Error("Failed to process", e);
throw;
}
}
|
|
|
|
|
I think the discussion isn't about the inherent value of a try-catch block. It is the problems associated with simply making an exception go away with no logging or anything in an empty try catch.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
You should only use a try/catch if you plan to do something with the exception. Exception handling is intended to provide a defense mechanism, where you can actually handle the exception - what's the point of just consuming it? If you just catch the exception then you don't know that part of your code encountered a problem, so you end up masking problems from a user. As an example, what happens if you have a network connection open and connectivity is lost? If you are writing to the network stream, it's a good idea to know that it's closed unexpectedly during a stream write, so you can inform the user that the write didn't complete successfully.
thomforum wrote: Tell me one instance where you wouldn't prefer placing a try/catch in a method.
This, effectively, is blind optimism. Use exception handling for what it's intended for.
|
|
|
|
|
When I want the exception to bubble up to a higher level to be handled at a business process level where I can centralize problem logging and abort whatever transaction is going on at the time, which is most of the time.
Doing it your way would limit the exception to that function, where you'd have to throw a new exception to get it to go higher.
But, don't take my word for it. There's tons of articles on the subject: Google Results[^]
|
|
|
|
|
You'd want to handle the ThreadException[^].
If you want to swallow exceptions, do it there - after logging them or something like that. There's an example on the page on setting up basic exception-handling.
I are Troll 
|
|
|
|
|
Yes. See this[^] code snippet.
/ravi
|
|
|
|
|
to add try catch block u type try and give two tab entry using key board u will get the try catch block automaticly
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
