|
|
Are there any built in .NET functions for dealing with relative file paths? Specifically: if I have two absolute file paths:
<br />
string fileNameA;<br />
string fileNameB;<br />
and I want to change fileNameB to be relative to fileNameA. Is there any way to do this with .NET, or should I just roll my own? Even just a way to tell fileOpenDialogs to return string names relative to the current working directory would be helpful.
Thanks
Dave
|
|
|
|
|
How can I get the unmanaged pointer of a managed method in C# so that I can store it in an integer within unmanaged memory? Also, how can I wrap an object around a pointer, with In/Out capabilities? It sounds kind of complicated, but I believe it is possible somehow. I'm trying to use a DLL in my program, which creates and uses a custom structure (in this case in the unmanaged memory). Luckily, there is a function in the DLL which allows me to retrieve the address of the structure, and I know all of the members in that structure through documentation. The part that trips me up is that the structure stores pointers to functions, and in order to use the DLL the way I would like, I want to change those pointers to my managed C# methods. As for the structure itself, I would like to wrap a managed structure around a pointer so that I can access the fields within it as well as write to those fields, kind of like a two-way link between the managed and unmanaged memory...
I only wish there were an easier way to explain all this. Does anybody know what I'm talking about?
|
|
|
|
|
|
I wonder if there is a difference between sending a broadcast or a multicast message on a single network (IE does not require routing).
|
|
|
|
|
I am calling an external app and redirecting the StandardOutput and StandardError streams so that I can capture them and display them in a TextBox. My app hangs in my timer Tick method (set to 20ms) when there is a lot of data on the StandardError stream, it hangs in the ReadLine() method with no warnings or output or anything. It just sits there and doesn't do anything, this also happens with the other Read methods EXCEPT for ReadToEnd() which will work. Unfortunately ReadToEnd() doesn't allow me to dynamically update the TextBox with the output as it comes in from the external process (using Process). When there's only a few lines of output it works fine, so my guess is there's some overflow or something with the data coming in too fast, but I can't figure it out.
I've tried many different things to get this to work with no luck, so am posting here hoping that this is a known issue or some way around this. TIA
|
|
|
|
|
I have reviewed several articles and examples to start processes on remote machines. The problem I have is that I cannot make any interactive. If the processes is created on the local machine if works fine. Remotely, however, the process shows in the process list but not applications nor is it interactive. I have changed the remote machine's WMI service to "Interact with Desktop" with no success. Has anyone been able to accomplish this without a separate service running on the remote machines?
Thanks in advance!
Paul
|
|
|
|
|
Windows 2000 SP3 removed the ability to remotely start processes in interactive mode for security purposes. Windows XP has always disallowed this. It is likely the samples you are referring to were written prior to SP3. I'm sure there is KB article on this, but I couldn't find it. I believe there are workarounds, but they're not recommended.
|
|
|
|
|
Is there a way to turn off the underline of text on a linklabel control?
|
|
|
|
|
Does
LinkLabel.Font.Underline = false not work?
|
|
|
|
|
It doesn't.
Even if the link label used that property to decide if it should underline the link (it uses the LinkBehavior enumeration), the Underline property of Font is read-only.
Charlie
if(!curlies){ return; }
|
|
|
|
|
linkLabel1.LinkBehavior = LinkBehavior.NeverUnderline;
Charlie
if(!curlies){ return; }
|
|
|
|
|
|
I'm registering a well known service that itself loads other components dynamically as requested by the client. I'd like to be able to determine when the client becomes disconnected from the remote service (say, if the connection is broken) so I can unload those components. I've read some things about connection lifetime services, but in my testing, they didn't
seem to work.
Has anyone done this and can point me in the right direction?
Thanks!
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
You may not like this answer....I had a situation where I had users from all over the country connecting to a remote object. I had the need to do two things: show everyone who is using the server -and- b) know when one of the users lost their connection.
My approach was to deploy a global object. It is a Singleton. It holds an array of those connected to the server and has a 6 hour lifetimeservice. This helps to assure I do not lose my name list while users are on but inactive.
I have each client connect to the global object and execute PublishIdentity("name");
I then have two threads running:
thread a) on client sends pings (NotifyGlobal("name")) to the global object every 15 minutes telling it the client is alive.
thread b) on server checks lists for users who did not respond in more than 30 minutes. Those are purged from the list.
When there is nothing in the list and my time expires I am purged. I use that to indicate I have to shut down my thread in the destructor. You could use the zero count to indicate when to clear your objects.
_____________________________________________
Of all the senses I could possibly lose, It is most often the one called 'common' that gets lost.
|
|
|
|
|
theRealCondor wrote:
You may not like this answer
Actually, it's a great answer! I hadn't even thought about doing my own lifetime service management. I guess sometimes I can't see the forest for the trees!
Thanks!
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
Great!
It works well for me. The 15 minute thread on the client dynamically updates a box on their workstation showing them who is on the server in real-time.
Once I got all of the remoting working, implementing this addition was so simple I could never let management know. (You'll get lots of kudos for implementing something so simple yet looks so complex)
_____________________________________________
Of all the senses I could possibly lose, It is most often the one called 'common' that gets lost.
|
|
|
|
|
I've been struggling with a remoting problem that is somewhat similar. In general terms:
- N number of clients talking to a server.
- Any client can alter privileged data but only one can do it at a time.
Sounds deceptively simple right? The trick is that being remoted over the web transport the server can't "ping" the client because of network topology routing isn't guarenteed (thinks like NAT are a good but often a necessary evil). Some of the operations can be a little long so just keying in on "time on CPU" isn't sufficient.
So Client 0 grabs the privileged resource to manipulate locking out other clients but something goes hiddeously wrong. Wrong to the point where no exception can be caught. This might happen if the machine is disconnected or the CLR is just plainly forced to unload. The server still thinks Client 0 is the only one altering the privileged resource and won't let any of the other clients access it.
I can't come up with a clean way to keep the system sane from unnatural disconnects. Because of other parts of the application and because ultimately the CLR unloading is beyond the scope of any runtime code the only way to "fix" hanging connections is to manulally kick dead connections.
I've tried but failed to find a way to handle this beyond handling it manually. What good are machines if I have to contantly fix things for them? If anyone has any good insight into how to handle this type of problem I'd love a good hint.
|
|
|
|
|
Tom Larsen wrote:
The trick is that being remoted over the web transport the server can't "ping" the client because of network topology routing isn't guarenteed
Hmmm. You can't do what's suggested here?
http://www.codeproject.com/script/comments/forums.asp?msg=735472&forumid=1649#xx735472xx[^]
Notice that the server doesn't do the pinging. Rather the client does and automatic, erm "echo?".
Anyways, what you say is interesting also from the point of view of what I'm working on, which gives the server the ability to call client components as well. I wonder how well it works across a firewall or other devices.
I guess I have a couple questions about your architecture--why is client 0's transaction partitioned in such a way as to hold the lock across transactions? It seems that the server should either not allow that or buffer the transactions until they can be all executed. Barring that, what if you put a timeout wrapper around such transactions that cancels them if they fail to complete within a specified time?
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
Sorry about the vagueness in the example. I would like to give out the exact nature of the application but I'm not at liberty to give out the fine deatils. Besides its a boring application.
In general it behaves like this your standard transactioned setup
LimitedRemoteResource res = null;
try
{
res = new LimitedRemoteResource();
res.Allocate();
this.MethodDoesSomething(res,argsA);
this.SomeOtherMethodDoesSomething(res,argsB);
....
....
}
finally
{
if(res != null)
res.Release();
}
If LimitedRemoteResource is a remoted type, there seems little that can be done to to be absolutely sure the finally block is reached and the resource is unallocated. Even if the code all works but the network is disconnected, calling Release won't work because server isn't reachable.
The example I gave was just supposed to highlight a general problem I'm constantly running into in remoted frameworks. A client in the remoting framework requests a resource from a pool from the server but the client ends up disconnecting before the resource is returned. Because its in a disconnected state there is no way for the client to contact the server to tell them of this problem (duh, it wouldn't be in a disconnected state if it could).
On the server side, you can't guarentee when if at all any of the server representation of the objects will be disposed and behaves more like the CLR is just unloaded/killed than it is asked to quit when the web server recycles threads. I've tried implementing crazy watching schemes like mentioned in the link where one thread watches for signs of life from the other but the it behaves on cleanup like th CLR is just unloaded instead of asked to exit/dispose. I get no indications at all that Dispose on any remoted object is being called when the web server does its normal thread cleanup or is forced to (ie. server reset).
So I am stumped. I *think* I need a "CLR Unloading" type event on the server.
|
|
|
|
|
Tom Larsen wrote:
In general it behaves like this your standard transactioned setup
I see your problem! Do you have to do it that way, where the client locks the resources on the server? Can't you buffer the whole transaction on the server?
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
The reason why the code is laid out like this is to take advantage of polymophism between different versions. LimitedRemoteResource is derived from a general BaseResource object. For one configuration you use a different object that uses different network protocols than the Remote version with the same BaseResource behavior.
I keep seeing the ultimate solution is to transact the thing on the server side but that ruins some of the code reuse (or at least force people to majorly rewrite their stable systems). It can be done but if I could just flat out avoid it if I got the right event.
One other thing I've noticed at least with IIS 5 and ASP.Net: Dispose isn't assured. I implement IDisposable on the resource object but the destructor is never called. So if in the normal operation on the server the lifetime of an object has expired I don't see a Dispose. In a more extreme case, if the server has to be reset or the machine is rebooted there is no way to Dispose opened resources. This seems to indicate that the web server recycles threads and resources by outright killing processes. The CLR just stops what it is doing and no more code is given a chance to execute. Its kind of a double headed problem. If the CLR is ever unloaded on either the client or server then the whole thing breaks down.
So here I am. If the server did a clean exit on the CLR I suspect that the system would just work out. Since I'm never given the chance to Dispose object properly I'm kind of sunk. I guess the lesson is to somehow work managed resources on only one side of any parallel system.
|
|
|
|
|
I just jumped into this conversation.
I assume that the change of priveledge (or whatever the change is) occurs via a method (or collection of methods) executed on the server. To guarantee that only one gets at the object, and only one, yet users are not blocked, then just use the lock{} command.
public bool UpdateThePriveledge(object orignalValue, object newValue)
{
lock
{
try{
res = new LimitedRemoteResource();
res.Allocate();
this.MethodDoesSomething(res,argsA);
this.SomeOtherMethodDoesSomething(res,argsB);
....
....
}
finally
{
if(res != null)
res.Release();
}
}
public bool PublishIdentity(string name)
{
}
public void NotifyServer(string name)
{
}
The lock will single thread, yet outstanding users will wait for the unlock. This is the standard way to make multi-updates thread-safe. Even if the code craps out, once you leave the method via the finally{}, you will unlock the method for the next user.
The NotifyServer call is what I mean by 'pinging' the server. If you can remote to call UpdateThePriveledge, you can call to NotifyServer that you are alive. No real 'ping' is meant here.
_____________________________________________
Of all the senses I could possibly lose, It is most often the one called 'common' that gets lost.
|
|
|
|
|
The client code is not the real issue. If something bad happens to cause a disurption in the network or the client application crashes, it effects other client users. This type of locking will work for multi-threaded applications, not for multi-user applications. The client side code snippet shows Marc why I was having issues with remoted objects when they disconnect. In this case if the CLR Is unloaded on the client side there is never a clean up for the resource.
The fastest solution seems to be catching some "unloading CLR" event. The best solution would be to rewrite the code so that resource doesn't span mulitiple application domains.
|
|
|
|
|
This is a really cheap method but it had worked for me. You simply allow a ressource for a certain time.(Like 3 minutes). In this case it will become the client problem. (Also this will prevent some clients of abusing of their privilegies and of keeping the same ressource for too long.)
|
|
|
|