[Mono-dev] Installing policy file in the GAC?
Hi, I'm writing an install script that places an assembly into the GAC using gacutil. However, with the assembly, I also need to install a policy file to control backward compatibility with previous version. I know that the policy file needs to go into the lib/mono/gac directory. But how do I get it there? gacutil won't install a policy file in the GAC because the policy file isn't an assembly. So, obviously, I have to copy it there from the install script. But how can the install script find out where Mono is installed? Is there any command I can use to get at the Mono installation directory? Thanks, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Installing policy file in the GAC?
Michi Henning wrote: But how can the install script find out where Mono is installed? Is there any command I can use to get at the Mono installation directory? Never mind, I figured it out. Thanks, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Control-C handler
Jonathan Pryor wrote: So why can't setting a volatile variable within a signal handler be supported? And/or use a Constrained Execution Region to *ensure* that the signal handler is JITed before the signal is emitted (does mono even support CERs yet?)? Something to support signal handling would definitely be useful. I'm currently in the situation where I'm maintaining a code base that must run on both .NET and Mono. The code is a middleware library (www.zeroc.com) that must allow allow applications to react to signals so they can shut down themselves and the Ice run time in an orderly fashion. Under Windows, the code uses P/Invoke to call SetConsoleCtrlHandler so it can intercept Ctrl-C, Ctrl-Break, and shutdown, logoff, and window closure. With Mono, I'm pretty much stuck because there is no equivalent mechanism. As far as I can see, the only option to achieve equivalent functionality is to create a C library that sets the necessary signal handlers and to then P/Invoke into that library from my C# Mono code. But that sort of defeats the purpose because I'd rather not ship a DLL for every possible platform Mono runs on. Console.CancelKeyPress, which was added with .NET 2.0, unfortunately doesn't work for this purpose: it only intercepts keyboard interrupts, but doesn't trigger on logoff, shutdown, or window closure. One could argue that all this is a limitation of .NET, which should offer a way to reliably intercept process termination. But, under Windows, I at least get an acceptable work-around in the form of SetConsoleCtrlHandler whereas, with Mono, I don't. So, anything to improve on this situation would be great. While I understand all the arguments about what can and can't safely be done from within a signal handler, the need to react to signals and perform some clean-up before a process goes away is a real-world requirement. If Mono offered at least rudimentary support for signal handling that doesn't require P/Invoke and external non-standard libraries, it would at least allow me to then build something on top of that. Right now, I can't do anything much at all, as far as I can see. Cheers, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] No local and remote endpoint for non-blocking connected socket
r different distributions. So, what I'm looking for is a way to get the local and remote endpoint from a socket that was connected non-blocking, but without having to use P/Invoke. If anyone has a suggestion, I'd be most grateful. Cheers, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What's with bugzilla?
Michi Henning wrote: At the bottom of that error page, I'm asked to validate my email. When I follow that link, I get to a page that asks me to enter the validation code I received, but I've never received any such email. I should have looked more closely: on that page is also a link that allows me to initiate the validation process manually. All is well now, I can talk to bugzilla again :-) Cheers, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What's with bugzilla?
Vance Baarda wrote: Something is definitely not working. I just got a nasty crash from bugzilla when I tried to sign in again: Sorry that bugzilla's giving you trouble. I agree that this looks like a crash, but it's not. The mechanism that bugzilla provides for custom error messages is not very good. Yes, the customer experience was somewhat lacking ;-) At the bottom of that error page, I'm asked to validate my email. When I follow that link, I get to a page that asks me to enter the validation code I received, but I've never received any such email. I see that you validated your email address at 09/24/2007 16:43 (Utah time). So I assume it's working for you now, yes? Yes thanks! When I tried again, I found that the error page has a link that allowed me to trigger the validation email manually, which I did. Everything is working for me now, thanks! Cheers, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Casting bug with generic collections
I would have put this into bugzilla, but it wouldn't let me, so I'm reporting it here... The code below compiles and runs fine with VS 2005 and prints a. With Mono 1.2.4, I get a cast exception: Unhandled Exception: System.InvalidCastException: Cannot cast from source type to destination type. at System.Collections.Generic.Dictionary 2+KeyColleciton[System.String,System.String].System.Collections.ICollection.CopyTo (System.Array , Int32 ) [0x0] Here is the code: System.Collections.Generic.Dictionarystring, string d = new System.Collections.Generic.Dictionarystring, string(); d[a] = b; System.Collections.ICollection keys = d.Keys; object[] keyArray = new object[d.Count]; keys.CopyTo(keyArray, 0); System.Console.WriteLine(keyArray[0]); Cheers, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] What's with bugzilla?
I just tried to create a new bug in bugzilla and found that I had to create a Novell account, which I did. When I then tried to submit the bug, I was told that access policies don't allow me to do that. Is bugzilla defunct, or just broken? Thanks, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] ANNOUNCE: Ice 3.0 released
Hi, we've just released Ice 3.0. (For those of you who haven't heard of it, it's a multi-language and multi-platform middleware.) Some highlights: improved C# and VB mapping and a new grid service. And, of course, it works with the latest Mono :-) See http://www.zeroc.com/vbulletin/showthread.php?p=8081#post8081 for the official announcement. Cheers, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] machine.config not found on Windows
Hi, I've just installed Mono 1.1.8. When I try to run one of my binaries, I now get (under cygwin): $ mono ./server.exe Ice.DNSException: GetHostName failed --- System.TypeInitializationException: An exception was thrown by the type initia lizer for System.Net.Dns --- System.Configuration.ConfigurationException: Cannot find C:\cygwin\opt\mono\etc:\mono\1.0\ machine.config () in 0x000a6 System.Configuration.DefaultConfig:Init () in 0xd System.Configuration.DefaultConfig:GetConfig (System.String sectionName) in 0x0001a System.Configuration.ConfigurationSettings:GetConfig (System.String sectionName) in 0x000b5 System.Net.Sockets.Socket:CheckProtocolSupport () in 0x7 System.Net.Dns:.cctor ()--- End of inner exception stack trace --- in 0x0 unknown method in 0x00078 IceInternal.Network:getLocalHost (Boolean numeric)--- End of inner exception stack trace --- in 0x00132 IceInternal.Network:getLocalHost (Boolean numeric) in 0x00076 IceInternal.DefaultsAndOverrides:.ctor (Properties properties) in 0x002b1 IceInternal.Instance:.ctor (Communicator communicator, Properties properties) The same code base used to work with Mono 1.1.6, so I suspect that this is due to a configuratin/installation problem. (I installed using the Windows installer on the download page.) Thanks, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] HasShutdownStarted race?
Finalizers are run by one thread, so once you are in one, no new objets will get finalized behind your back. However, I'm not sure if the spec promises that at all. No, no such promise in the spec. In fact, some MS people are talking about using more than one GC thread in future releases, and that would be perfectly compliant with the spec. Are they talking about a parallel gc (I think they already have one of those) or parallel finalization? The are talking about parallel finalization. See http://blogs.msdn.com/cbrumme/archive/2004/02/20/77460.aspx near the beginning, points 5-8 and the para that follows. Anyways, if they change this, you wouldn't be the only one affected. If you need more info, best to ask them. I don't like my chances... At any rate, it seems that the guarantees for HasShutdownStarted will eventually need to be tightened, so the condition cannot change during the execution of a finalizer. Cheers, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] HasShutdownStarted race?
Finalizers are run by one thread, so once you are in one, no new objets will get finalized behind your back. However, I'm not sure if the spec promises that at all. No, no such promise in the spec. In fact, some MS people are talking about using more than one GC thread in future releases, and that would be perfectly compliant with the spec. OTOH, HasShutdownStarted probably *could* change in the middle of the method. But it won't matter. I think it does matter, at least in some cases. In my situation, I have finalizers that need to access other objects during finalization. Normally, that's no problem: when one of those objects gets collected, the finalizer works just fine. Except during shutdown, once System.Environment.Exit() has been called. Because objects can be finalized in any order during shutdown, the finalizer now can no longer safely call into other objects and has to avoid doing that, hence the test for HasShutdownStarted. But, if the condition can change halfway through the execution of a finalizer, that's not very useful. And, because the GC runs asynchronously to the rest of the program, I cannot guarantee that I won't call Exit() while the GC is in the middle of some finalizer. As long as there is only one GC thread, not a problem: even if the condition changes halfway through the execution of a finalizer, that finalizer will still successfully complete, and then HasShutdownStarted becomes true for all the remaining finalizers. But, with multiple GC threads, that's no longer the case. What worries me is that the documentation makes no guarantee as to when the condition can change. And, if I rely on HasShutdownStarted as suggested by MS, it seems I run the risk of my code breaking on a future .NET (or Mono) version. Cheers, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] HasShutdownStarted race?
Hi,
System.Environment.HasShutdownStarted is the officially recommended way
of protecting finalizers against accessing finalized objects
(see http://msdn2.microsoft.com/library/xw9chd06(en-us,vs.80).aspx).
What worries me is that I'm not sure this is free from race conditions.
For example:
~SomeClass()
{
if(!System.Environment.HasShutdownStarted)
{
_mem1.foo();
_mem2.bar();
_mem3.baz();
// etc...
}
}
I can find nothing in the documentation that would guarantee that the
condition cannot change halfway through the execution of a finalizer,
for example, if System.Environment.Exit() is called from another thread.
The only way this would be possible would be for the GC and Exit()
to interlock on setting HasShutDownStarted to true, so that the value
of the property cannot change halfway through the execution of a finalizer.
But, as far as I can see, that's not happening in the code.
Comments, anyone? Is this a potential bug?
Cheers,
Michi.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Assembly binary compatibility?
In general, adding or removing an override is not a breaking change. Finalize works by chaining to the parent using base.Finalize. calling a method on base will always say call my direct parent.Method. In the JIT we would in the debug build see: my direct parent has the finalize method so call that, but in the non-debug build see my direct parent doesn't have a finalizer, so lets try one in the parent of that class. Sadly, due to some limitations in System.Reflection, MCS does not implement this correctly. http://bugzilla.ximian.com/show_bug.cgi?id=26204 As you can tell, thats a pretty old bug ;-( Thanks for the explanation, Ben! What about other changes though? Is it safe to add public data member? Safe to add a public method? Safe to add a private method or data member? Basically, what I'd like to find is a list that details exactly what is and isn't binary compatible. Cheers, Michi. -- Michi Henning Ph: +61 4 1118-2700 ZeroC, Inc.http://www.zeroc.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Assembly binary compatibility?
Hi,
I'm interested in figuring out exactly what kind of change to an assembly
is binary compatible. I've browsed the doc a fair bit, but I can't find a
comprehensive list of what actually constitutes binary compatibility.
Could someone point me at an authoritative list?
One question in particular I am interested in. Consider an object such as this:
class SomeClass
{
// ...
public void destroy()
{
lock(this)
{
// Clean up some things here...
_destroyed = true;
}
}
#if DEBUG
~SomeClass()
{
if(!System.Environment.HasShutdownStarted)
{
lock(this)
{
if(!_destroyed)
{
System.Console.Error.WriteLine(SomeClass wasn't
destroyed!);
}
}
}
}
#endif
private bool _destroyed = false;
}
Note that the destructor simply checks whether destroy() was called before the
instance is collected and that this is required only for a debug build. In
order to save the cost of acquiring the lock (and to avoid the cost of calling
the
destructor altogether), the entire destructor is made conditional.
Suppose I build the assembly without DEBUG defined and install it in the GAC.
I also compile a program that uses the assembly, but both the program and the
assembly are compiled *with* DEBUG defined. If I then later take the program
(but not the assembly) and run the program compiled *with* DEBUG against
the assembly compiled *without* DEBUG, will the program still work?
Cheers,
Michi.
--
Michi Henning Ph: +61 4 1118-2700
ZeroC, Inc.http://www.zeroc.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] unref on 1912 called when ref was already 0
Hi, I'm getting messages such as the following: ** (../../../test/Ice/operations/server.exe:25872): WARNING **: : unref on 1912 called when ref was already 0 These happen sporadically, and only on a dual-CPU machine, which makes me think that some kind of race condition is involved. I only see those messages when a process is about to shut down. I have no idea what the messages mean -- can anyone suggest a possible cause? Thanks, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] Re: [Mono-devel-list] Mono 1.0.1 released
Duncan Mak wrote: Hello all, An update of the Mono 1.0 release is now available for testing. You can find source tarballs and RPM packages for the 1.0.1 release here: http://go-mono.com/archive/1.0.1/ Please test the packages and tarballs and report any problems you find. If all goes well, we'll do our final testing and announce the 1.0.1 release to the public and update the web site tomorrow. I just tried unpacking the mcs archive: $ tar zxvf mcs-1.0.1.tar.gz tar: This does not look like a tar archive tar: Skipping to next header tar: Archive contains obsolescent base-64 headers tar: Error exit delayed from previous errors I'm getting the same error for the mono tarball. (This is on RH8.) Cheers, Michi. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
