[Mono-dev] ANN: TestDriven.NET 2.5 Beta + Visual Studio Express
Hi Folks, I have just released a version of TestDriven.NET that works with the Visual Studio 2005 Express Editions. It has been tested with C#, VB, C++ and J# Express. For more information about using this feature, please read the following post: http://weblogs.asp.net/nunitaddin/archive/2007/04/02/express-sku-support.aspx This version comes packaged with NUnit 2.4 Final and NUnit 2.2.10. If you have Mono installed a 'Test With... Mono' option will appear. This has been confirmed to work with Mono 1.2.3 and should work with future versions. Best regards, Jamie. -- http://www.testdriven.net http://weblogs.asp.net/nunitaddin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Quoting Paolo Molaro [EMAIL PROTECTED]: On 04/03/07 [EMAIL PROTECTED] wrote: There is a tool to convert PE executable (with PPC code) in their .xex format. However, there were issues : 1/ AOT is working only on x86 right now, according to http://tirania.org/blog/archive/2006/Aug-17.html It also works on amd64. support for ppc would need to be added, but it is not a big issue. 2/ And even if it's ok, the more important problem is that according to the same post, it still need JIT at some place. Yes: we'd need a few changes to avoid jitting at all, but it is doable. It would really be nice ! Don't hesitate to let me know as soon as those two points are done and I'll give it a try. 3/ When working on it, I tried to produce PE file with PE PPC Big endian target with binutils, and it was really painful, it's not really supported anymore (I speak of PE format only of course, it's well supported in other cases). Currently the PE format would be generated by the assembler/linker. You'd need to write some code to be able to generate directly the PE binary file. Yep, anyway I think code is more or less done, it would just require some time to reactivate it. ReactOS project could be of some help here as they did the same thing (they had a binutils patch for ppc-pe). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
On 04/03/07 [EMAIL PROTECTED] wrote: Was anyone able to determine if the old XBOX (x86) emulator or the xbox 360 CLR runtime do any jitting? It would be very surprising if they didn't do it and if they did, the European Commission is very likely interested in how they do it (hint, hint:-). I think the XBOX 360 CLR runtime does JITing, but well, Microsoft got a better access to console internal than us. Sure, that's a good reason for the European commission to investigate why they still adopt anti-competitive practices. If they do jitting, other people developing for the platform should be allowed to have the info do it as well. Hopefully the game industry will pressure them as well. The XBOX360 changes are pointless since it seems not possible to make it working. There is definitely interest and it is likely possible to make it work using the AOT backend and the PE file converter you mentioned, so I don't think the changes are pointless: they will enable other interested people to help you with your efforts. If you have other reasons that prevent you from contributing the code that's understandable. About the debugger, it's more a prototype right now, but I will probably work on it again if the code to get my monobind wrapper working is included in mono source tree (I posted the patch at http://lists.ximian.com/pipermail/mono-devel-list/2007-March/022949.html, I dunno if it was the right place for that). I'll review it in a bit, I was on vacation the last few days. Nevertheless, if it never happens, I might drop the sources of that prototype as a base (I nearly managed to do singlestepping and variable inspection with class definition extracted from runtime context). Did you check the mono*describe* functions in metadata/class-internals.h? lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoBind - C++ bindings library [include Mono Patch]
On 03/28/07 [EMAIL PROTECTED] wrote:
As I worked on a C++ binding library for mono, very close to
boost::python/luabind syntax, I had few minor modification to do in Mono
sources. The patch is attached.
I was wondering if it was possible to include them in mono.
The missing thing was the possibility to bind a pointer argument to an
internal
call. It is required in order to make all the C++ wrapper/proxy statically
linked through template metaprogramming.
[...]
Later, I would like the registration code to auto-generate C# header.
I think auto-generation is the only option, unless this is supposed to
be used for very few classes.
Anyway, I took a look at the code, but I don't see a reason why the core
of mono would need changes for this, you can do it all without any
mono changes.
What you basically are doing is that, given a icall method declaration,
to actually call a function with a different signature. Why not use the
correct signature in the first place?
[C code (or C-representation of the C++ ABI?)]
void icall (void *this_ptr, void *hidden_arg, int a);
[Old C# code: mono core changes needed because the signature is incorrect]
[MethodImplAttribute(MethodImplOptions.InternalCall)]
extern public void Test (int a);
[New C# code: no core mono changes needed]
[MethodImplAttribute(MethodImplOptions.InternalCall)]
extern void Test (IntPtr hidden_arg, int a);
static readonly IntPtr Test_hidden_arg;
public void Test (int a) {
Test (Test_hidden_arg, a);
}
And you will initialize Test_hidden_arg as part of the binding startup
code with the embedding API or even with an icall in C#:
static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig (vi);
where vi means void for the return type and i is the first argument of
type int, though there are also other options, like (using params arrays):
static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig (null,
typeof (int));
This makes it much more flexible and also much easier to deal with if
you automatically generate the C# side.
lupus
--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Quoting Paolo Molaro [EMAIL PROTECTED]: On 04/03/07 [EMAIL PROTECTED] wrote: Was anyone able to determine if the old XBOX (x86) emulator or the xbox 360 CLR runtime do any jitting? It would be very surprising if they didn't do it and if they did, the European Commission is very likely interested in how they do it (hint, hint:-). I think the XBOX 360 CLR runtime does JITing, but well, Microsoft got a better access to console internal than us. Sure, that's a good reason for the European commission to investigate why they still adopt anti-competitive practices. If they do jitting, other people developing for the platform should be allowed to have the info do it as well. Hopefully the game industry will pressure them as well. By the way, I sent yesterday a mail to MS in that sense. But well, we all know how it will end :) The XBOX360 changes are pointless since it seems not possible to make it working. There is definitely interest and it is likely possible to make it work using the AOT backend and the PE file converter you mentioned, so I don't think the changes are pointless: they will enable other interested people to help you with your efforts. If you have other reasons that prevent you from contributing the code that's understandable. No, that's no problem for me to release it (still it would need some polishing before doing so). However, I also had to port glibc first, so it's kinda messy. What I dont know is if it's legal to release code using this xdk, since it's not available for public... (even headers). I'll ask and let you know. About the debugger, it's more a prototype right now, but I will probably work on it again if the code to get my monobind wrapper working is included in mono source tree (I posted the patch at http://lists.ximian.com/pipermail/mono-devel-list/2007-March/022949.html, I dunno if it was the right place for that). I'll review it in a bit, I was on vacation the last few days. Nevertheless, if it never happens, I might drop the sources of that prototype as a base (I nearly managed to do singlestepping and variable inspection with class definition extracted from runtime context). Did you check the mono*describe* functions in metadata/class-internals.h? Yes, that's what I use if I remember right. Introspection is done with mono api itself (and that's why it is nice ! ;p). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoBind - C++ bindings library [include Mono Patch]
Quoting Paolo Molaro [EMAIL PROTECTED]:
On 03/28/07 [EMAIL PROTECTED] wrote:
As I worked on a C++ binding library for mono, very close to
boost::python/luabind syntax, I had few minor modification to do in Mono
sources. The patch is attached.
I was wondering if it was possible to include them in mono.
The missing thing was the possibility to bind a pointer argument to an
internal
call. It is required in order to make all the C++ wrapper/proxy statically
linked through template metaprogramming.
[...]
Later, I would like the registration code to auto-generate C# header.
I think auto-generation is the only option, unless this is supposed to
be used for very few classes.
Anyway, I took a look at the code, but I don't see a reason why the core
of mono would need changes for this, you can do it all without any
mono changes.
What you basically are doing is that, given a icall method declaration,
to actually call a function with a different signature. Why not use the
correct signature in the first place?
[C code (or C-representation of the C++ ABI?)]
void icall (void *this_ptr, void *hidden_arg, int a);
[Old C# code: mono core changes needed because the signature is incorrect]
[MethodImplAttribute(MethodImplOptions.InternalCall)]
extern public void Test (int a);
[New C# code: no core mono changes needed]
[MethodImplAttribute(MethodImplOptions.InternalCall)]
extern void Test (IntPtr hidden_arg, int a);
static readonly IntPtr Test_hidden_arg;
public void Test (int a) {
Test (Test_hidden_arg, a);
}
And you will initialize Test_hidden_arg as part of the binding startup
code with the embedding API or even with an icall in C#:
static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig (vi);
where vi means void for the return type and i is the first argument of
type int, though there are also other options, like (using params arrays):
static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig (null,
typeof
(int));
This makes it much more flexible and also much easier to deal with if
you automatically generate the C# side.
Yes you're right, that's the first approach I took. It's just I felt it was
cleaner to do it the other way. But well, since those definitions are
auto-generated I suppose it's not a big deal doubling everything.
Thanks for the review.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Problems with the Session_end event
Hello, I'm having problems with the Session_End event being raised multiple times for the same sessionID. I've also reported a bug related to this issue, bug #81140. Can anybody help me with this? I would work on the problem, but I don't know where to start. Some ideas would be appreciated. Thanks. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] ChangePassword patch
Hello,
Attached is a patch for ChangePassword control. The ProcessChangePasswordEvent
is calling MembershipProviderInternal.ChangePassword method which is throwing
ArgumentException in different situations - Password too short, Password does
not match regular expresion etc. Instead of allowing the exception to
propagate, the ProcessChangePasswordEvent should catch it, call the
OnChangePasswordError and set the failure message according to the exception
message.
Best regards,
Dumi.
Index: mcs/class/System.Web/System.Web.UI.WebControls/ChangePassword.cs
===
--- mcs/class/System.Web/System.Web.UI.WebControls/ChangePassword.cs (revision 75341)
+++ mcs/class/System.Web/System.Web.UI.WebControls/ChangePassword.cs (working copy)
@@ -756,23 +756,32 @@
if (loginCancelEventArgs.Cancel)
return;
- if (MembershipProviderInternal.ChangePassword (UserName, CurrentPassword, NewPassword)) {
+ try {
+if (MembershipProviderInternal.ChangePassword (UserName, CurrentPassword, NewPassword)) {
+
+ OnChangedPassword (args);
+ _showContinue = true;
-OnChangedPassword (args);
-_showContinue = true;
+ if (_mailDefinition != null)
+ SendMail (UserName, NewPassword);
+}
+else {
+ OnChangePasswordError (EventArgs.Empty);
+ string lastError = string.Format (
+ Password incorrect or New Password invalid. New Password length minimum: {0}. Non-alphanumeric characters required: {1}.,
+ MembershipProviderInternal.MinRequiredPasswordLength,
+ MembershipProviderInternal.MinRequiredNonAlphanumericCharacters);
-if (_mailDefinition != null)
- SendMail (UserName, NewPassword);
+ ChangePasswordContainer container = (ChangePasswordContainer) ChangePasswordTemplateContainer;
+ container.FailureTextLiteral.Text = lastError;
+ _showContinue = false;
+}
}
- else {
+ catch (Exception e) {
OnChangePasswordError (EventArgs.Empty);
-string lastError = string.Format (
- Password incorrect or New Password invalid. New Password length minimum: {0}. Non-alphanumeric characters required: {1}.,
- MembershipProviderInternal.MinRequiredPasswordLength,
- MembershipProviderInternal.MinRequiredNonAlphanumericCharacters);
ChangePasswordContainer container = (ChangePasswordContainer) ChangePasswordTemplateContainer;
-container.FailureTextLiteral.Text = lastError;
+container.FailureTextLiteral.Text = e.Message;
_showContinue = false;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] ActiveDirectoryMembershipProvider
The patch below enhances the usefulness of
ActiveDirectoryMembershipProvider under mono, but may not be acceptable
for inclusion in svn. I'm posting this in case some one else runs into a
similar problem as I encountered.
We have a Membership Provider that derives from
ActiveDirectoryMembershipProvider and then overrides Initialize and
ValidateUser. Our ValidateUser method looks in web.config and either
does an validation against AD or our legacy authentication scheme.
This works on mono (if configured to not use AD), as long as the
Initialize method in ActiveDirectoryMembershipProvider calls
base.Initialize. Calling base.Initialize is important as this is how
ProviderBase sets the Name property which lets the Provider be put into
a ProviderCollection. Without the Name, Adding the provider to the
collection fails with a ArgumentNullException.
Currently ActiveDirectoryMembershipProvider just does a throw
NotImplemented.
If instead we said:
mcs/class/System.Web/System.Web.Security/ActiveDirectoryMembershipProvider.cs.orig
2007-04-03 20:59:32.0 -0400
+++
mcs/class/System.Web/System.Web.Security/ActiveDirectoryMembershipProvider.cs
2007-04-03 20:59:50.0 -0400
@@ -118,7 +118,7 @@ namespace System.Web.Security {
[MonoTODO(Not implemented)]
public override void Initialize (string name,
NameValueCollection
config)
{
- throw new NotImplementedException ();
+ base.Initialize(name, config);
}
[MonoTODO(Not implemented)]
The class would be slightly more useful in the above scenario. Probably
this circumvents some policy about MonoTODOs, but again just want to
post this info somewhere for others to google. It might even improve
things just by calling base.Initialize and then throwing, as you could
catch that exception and still be in business. Thoughts?
jr
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
