Any chance the thread that initiated the BeginSend is ending before the
callback is received? This can happen if you're using a home-grown
thread pool. The system ThreadPool has special logic to ensure a thread
is never destroyed if there are pending IOCP requests.
Rick
-Original Message---
Hi Polo,
If you need to install prerequisites then yes you do need a setup program.
But in that case, you are not building a "smart client". One of the things
that makes them "smart" is that they don't require a setup program.
You still might be able to use the
section in your app's config file
Sure, I'm very familiar with the benefits of smart-clients (see my companies
website for some more info - http://www.kinitos.com/). My only question is
why rely on Assembly.LoadFrom? You can do no-touch deployment without using
LoadFrom at all. Perhaps I'm missing something, but I don't understa
I don't have experience doing this specific thing, so I can't necessarily
tell you what the best approach is. However, I'd suggest you re-think the
decision to use LoadFrom instead of Load.
What resources were suggesting you use Assembly.LoadFrom? It has some
advantages, but it introduces some c
Assemblies are loaded on demand (eg. when the first method to reference it
is JIT compiled). So another option is to isolate all code that uses the
3rd party assembly into specific methods, and avoid calling those methods
when you know the assembly isn't available. I'm not claiming this is
necess
Have you considered using async calls to the web service? In some
situations, using an async model can be much less error prone and better
performing than using an concurrent approach. In a lot of situations,
trying to model your algorithm in an async way is just too non-intuitive so
using multip
Sorry for the very late reply.
> I'm not sure this is true for StackOverflowException. I think the CLR
team
> is working on hardening the finalizer to stack-overflow exceptions... at
> least the ones that occur in managed code; it may always be prone to death
> and destruction via unmanaged stack
I agree that exceptions from C++ constructors can be dangerous, although you
can dealing with them safely if you're careful. Yes this is fine in .NET.
However, exceptions from C++ destructors are always dangerous, and this is
still true in .NET.
In C++, if an exception can escape a destructor, it
Before you build a dual Web Services + Remoting interface to your
application, I'd suggest you do some profiling. You may find that the speed
difference between Remoting and Web Services is relatively minor for your
application. They are two completely different stacks, and it's not obvious
to me
The approach that I have found to be most useful is to use the SyncBlk
command in SOS. If you're not familiar with it, SOS is a native debugger
extension that comes with the .NET SDK that provides access to CLR data
structures. I has a bit of a learning curve, but it is totally invaluable
when de
Since Workflow is a MBRO, it's instances live on the server and are accessed
remotely. You have to think about the behaviour you want here. Do you
really want all the Workflow objects to exist on the server, or do you want
to send them (Serializable) across the wire to the client? How long shoul
The X509Certificate class built into .NET is not very feature-rich. The
Microsoft.Web.Services.Security.X509.X509Certificate class included in WSE2
has a "GetSubjectAlternativeName()" method that probably does what you want.
Alternatively, you might want to look into the Mentails Certificate Servi
This has much more to with the network and routing config of the machine
then anything you would (or could) do programmatically - especially from
.NET code. What you want is that packets to the IP address of the server
you want to upload to are always routed through the VPN interface. You'll
want
This only applies when using COM+ synchronization
(System.EnterpriseServices.SynchronizationAttribute and ContextBoundObject).
If you exit the synch domain, then another thread can come and use the
method while you are waiting. Otherwise you continue to hold the lock used
for COM+ synchronization
Hi Stoyan,
Thanks for the detailed response! You have some interesting ideas, but I
think you're assuming that I control the code for 'B'. In most cases my
class ("A" in your example) will be invoking async operations on some system
class and so I can't influence things like the dynamic type of t
First, if you haven't already, you should checkout the performance info from
the .NET team [1]. Specifically, this article [2] on GC performance may be
valuable. Without understanding how the GC works it is relatively easy to
end up with code that it spending a lot of its time in GC. How high do
l state? Seems like this could be a common design pattern,
and I'm surprised at how complex it appears to be to get it right.
Thanks,
Rick
---
Rick Byers http://www.kinitos.com/
Kinitos: Distributed .NET sma
ven any two samples, calculate the average queue
length
between those two samples
- the queue is likely to go down to 0 and stay there for an extended
period of time without generating any
new N[i] values, so we also have the client factor in the current
instantaneous queue length
Your LoadFrom loaded the assembly into the "LoadFrom binding context". When
the object is received over remoting, the remoting infrastructure does the
equivalent of Assembly.Load("AssemblyName"), which only searches the "Load
binding context". The two binding contexts are kept isolated intentiona
o:[EMAIL PROTECTED]
> >
> > Thanks a lot Rick for you reply.
> >
> > Yes in fact that's why I was looking into using IPv6 as Microsoft
> > suggests.
> > My main reason for wanting to use IPv6 cause as you well stated the
> IPv4
> > solutions are merely hacks
By "the NAT problem", I assume you mean restoring end-to-end connectivity on
the Internet (when it is not intentionally disrupted by a firewall). There
are all sorts of ways of doing this with IPv4 ("bi-directional' connections,
UPnP, etc) but in my opinion they're all just hacks that greatly incr
In general remoting is supposed to interoperate between .NET 1.0 and 1.1,
however a few "bugs" slipped through (IPAddress and Comparer classes are the
only two problems I'm aware of). It is possible to work around these
issues, but it can be fairly complex if you want to do it transparently.
See
I'm assuming you're talking about remoting here. Its true a remoting call
into another AppDomain in the same process doesn't require a process context
switch and also saves some of the overhead of copying the serialized data
from one place to another. However, I'm guessing the savings of this is
t
> (Partial)
> LOG: Appbase = S:\bin\
> LOG: Initial PrivatePath = NULL
> LOG: Dynamic Base = NULL
> LOG: Cache Base = NULL
> LOG: AppName = NULL
> Calling assembly : (Unknown).
> ===
>
> LOG: Processing DEVPATH.
> LOG: DEVPATH is not set. Falling through to regular bin
On the client, if you're going to use 'Connect' to access your remote object
(as opposed to 'new MyRemotableObject'), then you can access it using an
interface (which you appear to want to do anyway). Instead of doing "typ =
Type.GetType(typeinfo)" on the client, you probably just want "typ =
type
Hi,
How are people dealing with changes in serialization format between .NET 1.0
and 1.1? For example, the IPAddress class is now represented internally as
a Byte[] instead of an Int64 (why it was ever an Int64 is beyond me). This
means that when it is serialized by the SoapFormatter or BinaryFo
Hi,
When GetType is called on a TransparentProxy, the CLR attempts to get the
real type of the object being proxied by calling
RemotingServices.GetType(TransparentProxy), loading assemblies as necessary.
In a normal remoting scenario where the implementation assembly is
unavailable, this will fail
Hi,
According to Ingo Rammer ("Advanced .Net remoting" page 106), the server
side HttpChannel automatically uses both soap and binary formatters and
detects which encoding has been chosen at the client side. I've never tried
this myself, but it should just work :)
Rick
-Original Message
28 matches
Mail list logo
