It would be nice, at this point, that Delegate-derived classes was not
sealed. Now I need a wrapper class to encapsulate a delegate ensuring a
call to EndInvoke when it is necessary... But it would be really a risk
calling that inside a IDisposable pattern: imagine what happen if
someone forget to
> contained the ref I need, but surely it can not be the idea to find it
> there.
I'm sure there's an API to get it, I just haven't run across it yet.
Historically, this information is made available via fusion.dll.
There's at least one sample of using fusion.dll in the .net sdk sample
directory (
Mike,
This is all pretty new for me, but only found the .ini file in C:\Documents
and Settings\mli\Local Settings\Application Data\assembly, and indeed it
contained the ref I need, but surely it can not be the idea to find it
there.
Again, asking for the properties of a gac-ed assembly using the
You're right - I'd completely forgotten about /ir. That flag does cause
gacutil.exe to record the original installed-from location (apparently
in the __AssemblyInfo__.ini file in the directory where the assembly is
placed in the GAC tree). That's why I said "that I know of", which
implies for "of
Mike,
I thought that's what gacutil -ir and gacutil -ur were for. If I'm wrong
-- which is probably the case, would you mind explaining the point of
the FILEPATH reference?
John
John St. Clair
Prosjekt- og teamleder
Reaktor AS
-Original Message-
From: Moderated discussion of advanced .
Thanks, this was a clear response.
I guess I'll have to look for another solution to store /dll config info,
possibly putting all *.dll.config files in the same fixed location.
The issue is that when you install an assembly into the GAC, no record
is made anywhere (that I know of) as to where the assembly originally
came from. In fact, the original dll need not exist anymore (can be
deleted, or as in the case of assemblies installed into the gac from
removable media such
> So the call from Win98 goes to a server and the server executes (and write
a
> log entry) and the Win98 throws an error upon receiving the reply, right?
That's right.
> I'd want to confirm that the Win98 boxes always fail (and only Win98) and
> then I might suspect the soap toolkit or some othe
Try
Assembly.GetExecutingAssembly().Location
Instead. According to msdn docs this is
~~
The location of the loaded file that contains the manifest. If the loaded
file was shadow-copied, the Location is that of the file before being
shadow-copied.
~~
Alternatively,
System.Reflection.Assembly.Ge
So the call from Win98 goes to a server and the server executes (and write a
log entry) and the Win98 throws an error upon receiving the reply, right?
I'd want to confirm that the Win98 boxes always fail (and only Win98) and
then I might suspect the soap toolkit or some other part of the installat
What really bothers me (aside from the failure itself) is the fact that
Windows 2K workstations and Windows XP
workstations in the same network are not affected by the problem whatsoever.
So for this moment I'm discarding general network configuration issues as
the cause and focusing instead on how
The official description for the 502 error is: "The request was not
completed. The server received an invalid response from the upstream
server."
Do you have a firewall involved? Is the target server flooded with traffic?
You might need to put a trace on the msgs from the target server to find out
This one has been a real pain in the neck. Every now and then our
application fails with the following message
** Exception Text **
System.Net.WebException: The request failed with HTTP status 502: Bad
Gateway.
at
System.Web.Services.Protocols.SoapHttpClientProtocol.ReadRe
This returns exactly the same string as the code I have been using, and the
GlobalAssemblyCache property returns also whether the assembly was loaded
from the gac or not.
The only thing I need is this string: 'c:\myAssembly.dll.config', whether
the assembly came from the gac or not, if possible re
14 matches
Mail list logo
