Component Versioning and the CLR - C# Discussion Boards

Dan Mos2-Dec-11 0:54

Dan Mos

2-Dec-11 0:54

Just like said before/above either throw the exception and handle it on the calling client,
or log it, return null and check for null on client.

catch(Exception ex)
{
     //either throw it;
     throw;
     //or log it and make the dt null
     dt = null;
}
return dt;

I recommend throwing it and handle the exception on the client calling method.

All the best,

Dan

modified 2-Dec-11 17:16pm.

BobJanova2-Dec-11 5:44

BobJanova

2-Dec-11 5:44

Unless this is a top tier interface function where exceptions are bad (and since it's doing database stuff, it shouldn't be), you should just let the exception escape, to be handled by the calling function.

Rob Philpott2-Dec-11 1:07

Rob Philpott

2-Dec-11 1:07

I'd say do nothing, unless you want to do some custom exception handling in your function. Exceptions are for exceptional circumstances and in my mind there's always been little point in catching an exception just to rethrow it. The error message in an exception is often useless without the stack trace as well.

It's up to the *calling function* to decide what to do in the event of an error, so it may handle the exception there or let it pass further up the call stack.

In particular stuff like this

try
{
}
catch (Exception ex)
{
    throw ex;
}

is pointless and bad as you'll lose the stack trace.

Regards,
Rob Philpott.

BobJanova2-Dec-11 5:45

BobJanova

2-Dec-11 5:45

If you just use

try { ... }
catch(Exception) { throw; }

(note, 'throw' not 'throw ex'), you don't lose the stack trace. It's still pointless but at least it's not harmful.

Rob Philpott2-Dec-11 5:50

Rob Philpott

2-Dec-11 5:50

Indeededoody!

Regards,
Rob Philpott.

PIEBALDconsult2-Dec-11 2:08

PIEBALDconsult

2-Dec-11 2:08

I agree with allowing the Exception to be thrown. You may also add some context to the Exception if you choose:

catch (Exception ex)
{
   ex.Data.Add("Method", "function");
   ex.Data.Add("myTableKey", myTableKey);
   throw;
}

Personally, I like to determine what type of Exception it is (timeout, deadlock, duplicate key, etc.) and wrap it in a custom Exception.

Component Versioning and the CLR

Eddy Vluggen2-Dec-11 7:30

Eddy Vluggen

2-Dec-11 7:30

Thanks for a good tip, +5 Thumbs Up | :thumbsup:

Bastard Programmer from Hell Suspicious | :suss:

Richard Andrew x641-Dec-11 16:43

Richard Andrew x64

1-Dec-11 16:43

I hate to admit that I still don't fully understand what happens when it comes to .NET versioning.

If I want to use an Infragistics control that was compiled against the 2.0 framework, in a 4.0 project, does this cause a mix of 2.0 and 4.0 objects in the same runtime environment?

For instance, if the 2.0 control creates a new Rectangle object, is that a version 2.0 Rectangle, while my 4.0 code would be creating version 4.0 Rectangles?

Or does all the code in the process run against version 4.0 objects?

The difficult we do right away...
...the impossible takes slightly longer.

Re: Component Versioning and the CLR

Not Active1-Dec-11 17:18

Not Active

1-Dec-11 17:18

2.0 code would know nothing about the 4.0 code so it could only create its own version. Only one version of an assembly can be loaded into the appdomian at a time so objects created will be from that version. However, it does get a bit tricky if you use codeBase[^] or assembly rediection[^]

No comment

Re: Component Versioning and the CLR

Richard Andrew x641-Dec-11 17:21

Richard Andrew x64

1-Dec-11 17:21

Thanks, that helps. I take note that only one version of an assembly can be loaded at a time, so that means that the 2.0 assembly will be using objects from the 4.0 version of the .NET framework.

The difficult we do right away...
...the impossible takes slightly longer.

Re: Component Versioning and the CLR

Rob Philpott2-Dec-11 2:46

Rob Philpott

2-Dec-11 2:46

Have a look at the modules window in the debugger. That'll tell you all the assembles that are loaded and their version.

Regards,
Rob Philpott.

C# Sockets

Sautin.net1-Dec-11 7:48

Sautin.net

1-Dec-11 7:48

K, I am relatively new to sockets so bear with me.

I have an experimental Client/Server socket application I am developing to replace an existing
legacy DCOM Client/Server architecture.

What i am trying to do is replicate the class interface of the legacy DCOM client classes in the TCP Socket client classes.

For instance
DCOM Client Call Signature:
Call on the client class to retrieve an array of information from the DCOM server.
int returnValue = client.GetArray(int arrayID, ref object values)

This client also receives updates from the server at regular intervals.

So my problem is with the new TCP Socket based class.

I have a thread within the client class that is listening for updates from the server.

Now I send a byte[] based call to the TCP server which returns a byte[] containing 2 integers and an array in this order: ResultOfCall(4 bytes) ArrayBytesLength(4 bytes) ArrayBytes(? bytes)

// send the request<br />
byte[] callSignature = GetSomeCallSignature(parameters);<br />
mySocket.Send(callSignature);<br />
<br />
// receive the function return value<br />
byte[] returnVal = new byte[4]<br />
mySocket.Receive(returnVal,4,0);<br />
int retVal = BitConverter.ToInt32(returnVal);<br />
<br />
// receive the array bytes length<br />
returnVal = new byte[4]<br />
mySocket.Receive(returnVal,4,0);<br />
int arrayLength = BitConverter.ToInt32(returnVal);<br />
<br />
// receive the array<br />
byte[] arrayBytes = new byte[arrayLength];<br />
mySocket.Receive(arrayBytes,arrayLength,0);<br />
<br />
// convert to an array from bytes<br />
object arrayValue = this.ConvertToArray(arrayBytes);

My problem is that the thread that is constantly checking for updates will read everything past the first receive(receive the function return value) and the program will lock up on the second receive
(i.e. receive the array bytes length). My question, is it only feasible to have two socket connections to the server class for each client? One for executing commands against the server and one for listening for events from the server. There really is no way to tell how many clients will be connected to the server, doesn't this open up a can of worms?

"All of us who served in one war or another know very well that all wars are the glory and the agony of the young."
Gerald Ford

Addy Tas1-Dec-11 12:45

Addy Tas

1-Dec-11 12:45

Hi, as i always say; it's software, anything is possible. First of all, depending on the Listen of the server you can connect as much clients as you need.
Second; would you really want to have it that way? If the other channel is only for a event so once and a while you could also use UDP for that, not that it really makes a difference but if you could broadcast the events the client would not need to bother about connecting to the server.

Next issue is naturally what you're sending /receiving. Make your life easier and build yourself a proper protocol where each packet at least contains the protocol version (certainly for UDP) or when connecting first exchange protocol versions.

Next about receiving data, there are several ways to do this and so far it seems that you have used the blocking way; you can also handle the receive in a async way, that frees the system to do other interesting stuff.

I think i gave you a lot to chew on but these are things you will need to consider sooner or later.

Let me know if you like more detailed info and i'll see what i can cook up for you.

Regards, AT

Cogito ergo sum

jschell1-Dec-11 13:39

jschell

1-Dec-11 13:39

Sautin.net wrote:
There really is no way to tell how many clients will be connected to the server, doesn't this open up a can of worms?

The Server has a thread call it A. Thread A accepts connections (creates a connection) specifically for that client.
The server then spins up a thread to deal with the connection, only that connection. So a new thread exists for each connection.
Thread A on the server then goes back to waiting for a connection.

So when client X does a connection the following happens.
1. Server opens accepting port.
2. Thread A gets a connection call on port and that creates connection X.
3. Server creates thread 1 and passes X to it.
4. Thread A goes back to listening for connections.
5. Thread 1 listens for input (your callSignature) using X.
6. Thread 1 gets msg and then sends response (bytes) on X.
7. Thread 1 can stop or go back to step 5.

Jitendra Parida - Jeetu1-Dec-11 21:41

Jitendra Parida - Jeetu

1-Dec-11 21:41

Hi,

When you want send and receive data from multiple sockets just using threading concept to connect socket when send data then you make thread sleep for receiving data. then make thread sleep for sending data.

Printing in C# on Thermal Printer

BobJanova1-Dec-11 23:52

BobJanova

1-Dec-11 23:52

You are making a common mistake in assuming that the 4 bytes you want for your header information will always be received together. This will be the case 99% of the time, but it's not guaranteed, and on a busy stream you may well get partial messages, which will send your whole receive logic out of line (i.e. if the calls to socket.Receive only get 3 bytes).

Receive will block until the data is available. Are you sure your server is actually sending (8+arrayLength) bytes?

I recommend you build your solution on top of an existing message-based TCP protocol like the one in my article[^], if you need the two way connectivity and don't feel like configuring WCF to do what you want. I think I saw another article that does something similar but allows you to send complex types, but I don't have a link to that handy.

Re: C# Sockets (Solved)

Sautin.net2-Dec-11 9:33

Sautin.net

2-Dec-11 9:33

I solved my problem, thanks for you replies. Laugh | :laugh:

"All of us who served in one war or another know very well that all wars are the glory and the agony of the young."
Gerald Ford

vijay.victory1-Dec-11 6:26

vijay.victory

1-Dec-11 6:26

Hi,
I am brand new to printing to a thermal printer using c# asp.net, and i need your help guys to give me where can i find tutorial
how can i connect and print to thermal printer using c#.
i am using VS 2008 PRO .NET 3.5

please help me to get started with thermal printing using c#

I am stuck here.

I have never failed,I just found 1000 ways that never works.
Regards,
Victory.

Dan Mos1-Dec-11 6:43

Dan Mos

1-Dec-11 6:43

If the printer supports IP/network(and it should) then I don't see the problem.

Simply send the byte[] to the printer's IP.(yeah a static IP is needed for this).

Usually the industrial/thermal printers come with a predefined header/logo file.
All you need to do is send it plus the other label info.
I/we can't possibly know how to help you on a specific printer label type.
Smile | :)

All the best,

Dan

vijay.victory1-Dec-11 7:07

vijay.victory

1-Dec-11 7:07

thnx dan,

i already tried that way.but of no use.

I want to print in the Bill/Invoice format. Can you help me about this?

I have never failed,I just found 1000 ways that never works.
Regards,
Victory.

Dan Mos1-Dec-11 7:19

Dan Mos

1-Dec-11 7:19

Sorry but I don't think I can help because:

I don't know the format of the label
I don't know the type and protocol of the printer

Here's how I did/do it(regardless of winapp/webapp):

Read the printer label format in a byte[] from a stream.
Add the actual label(s) info such as PN, Qty, Batch ... according to the label specs
Send the resulting byte[] to the printer IP

Even when using serial Connection from windows app I use the same technique(send the file/byte to the serial port).

Other possiblities:

Use a printServer and add the thermal printer to the print server.(never did it)
Connect the printer to USB.(only did it on win app)

All the best,

Dan