|
Yes - but haven't you encountered the scenario you're wiring pretty same object but every so often deserialization exceptions thrown?
dev
|
|
|
|
|
devvvy wrote: but haven't you encountered the scenario you're wiring pretty same object but every so often deserialization exceptions thrown?
No; what is your issue?
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
|
devvvy wrote: solution here
And a fairly obvious one. No wonder I never came across the problem.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
devvvy wrote: even on intranet, sending objects back and forth eventually you'd run into deserialization exception and to handle this client must resend the request, that's how we deal with this.
Not due to network-errors. What does the exception say?
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
blows up when System.Runtime.Serialization.DataContractSerializer attempts to ReadObject(byte[])
this said, one other suggested it could be threading issue... not sure but easy enuf to test out (... testing now...)
dev
|
|
|
|
|
I deal with it by sending messages, not objects. And of course insuring that I read the message correctly.
|
|
|
|
|
it's actually object graphs -
dev
|
|
|
|
|
Doesn't matter.
Sockets only send data. So anyway you want to send an 'object' it is still data.
And thus one sends a message not data, where the message contains data.
|
|
|
|
|
|
Is the application multi-threaded?
If the answer is yes, then you probably have a synchronization problem (not having synchronization at all is a big problem).
Considering you are using TCP/IP, I can't say about any other problem. My serialization works everytime... and I have some servers that use serialization for all their tasks, multi-threaded, and they work for years without receiving serialization exceptions.
|
|
|
|
|
|
At my company I am told to get this C# 2008 application to work that has been 'stored away' for a year. The programmer who wrote the application is no longer working for this company.
I have the following 3 references that need to resolved for ths application to work correctly:
1. I am missing a reference to the common.logging.dll. I clicked under references and selected the .net and com tabs. I did not find the common.logging.dll.
Is this some .net feature that I need to add to this solution file? If so, can you tell me how to locate this feature and add it to my solution file? If not, can you tell me where I can locate the common.logging.dll and how to attach the reference to my solution file?
2. My other 2 references are the names of 2 of the project files that are part of the applicable solution file. Thus I am thinking that I need to rebuild each of the two project files separately from the entire solution file to obtain the required dll files. To obtain the applicable dlls, I am thinking that I need to obtain a reference to each file in the bin/debug or bin/release folders?
Is obtaining the applicable dlls from the bin/debug or bin/release folders a good idea or not?
Can you tell me if what I am planning to do is correct and/or what change(s) you think I should make?
|
|
|
|
|
You need to locate common.logging.dll and add that to your project.
It might be a third party dll.
|
|
|
|
|
Would you have an idea of where I can obtain the common.loggin.dll?
|
|
|
|
|
Check your repository. You might find the source code for this dll lying around somewhere.
|
|
|
|
|
With a name like common.logging, I suspect it's a project that is internal to the company.
|
|
|
|
|
For the two references that are references to other projects within the solution, remove the references to the .dll and add project references. That will make the compilation tree and dependency checking work properly.
You will have to find common.logging.dll. That sounds like it could also be part of the solution, or a common library that's available in your company. It seems unlikely that a third party would release software under the assembly name prefix 'common' so it's probably internal.
|
|
|
|
|
I have the following question about you statement:"For the two references that are references to other projects within the solution, remove the references to the .dll and add project references".
Until you mentioned the above, I did not know there is a dll reference versus project reference. Thus can you tell me how to remove the dll reference so I can use the project reference instead? Hoe do you tell a dll reference from a project reference?
|
|
|
|
|
In VS when you right click on the references, I think it has 'Add Project Reference' and 'Add Reference'. Removing a reference is as easy as selecting it and pressing 'delete'.
|
|
|
|
|
Why doesn't this call back function get called?
Basically here is the code surrounding the declaratoini callback method:
[code]
webbrowser1 = new WebBrowser();
webbrowser1.LoadCompleted +=webbrowser1_LoadCompleted;
webbrowser1.Navigate(new Uri("http://www.google.com"));
[/code]
Should there be something more or are they in the wrong order?
The method, webbrowser1_LoadCompleted, is never called. I have put breakpoints in the callback method and the running program never reaches this method:
[code]
void webbrowser1_LoadCompleted(object sender, NavigationEventArgs e)
{
.
.
.
}
[/code]
|
|
|
|
|
I don't see a LoadCompleted() event in this class but I do see a DocumentCompleted()[^] event.
[edit]
I stand corrected, there is a LoadCompleted()[^] event, but it depends on which version of the WebBrowser is in use. Microsoft strike again.
[/edit]
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Had some down time and decided to screw around with RESTful web services since a lot of job ads want it nowadays.
I simply don't get it.
You lose the (IMO) biggest feature... WSDL / auto-client generation.
Ok, so the Linux snobs / internet geeks believe auto-client generation is evil, but from a developer standpoint, building a RESTful service takes a bit more time defining all the URLs and such, but the client takes a LOT more time since you have to hand parse and test all the requests & responses.
I've googled and it seems RESTful has WADL, but nobody really uses it, so its back to hand writing all that code.
What do you guys think about loosing the auto-client generation thing? If you have 1 or 2 methods / objects, BFD... but what about a large web service? You might need to write hundreds of methods.
Any thoughts?
|
|
|
|
|
This is not C#, please use the WCF forum.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
SledgeHammer01 wrote: Ok, so the Linux snobs / internet geeks believe auto-client generation is evil
You come on to this forum with blasphemy, yapping on about REST and full of WAD, and yet you fail to recognize the raw socket?
There "was" an option of asking an objective and non-religiously tainted question. So, now that we started it, whatever gave you the impression that there's something that's more efficient than a heavily customized HttpServer?
For those that missed it; post contains a "Joke" icon. Yes, I know, but I need to practice somewhere 
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
