solved: Re: [Mono-dev] problem get_UnsafeAuthenticatedConnectionSharing ()
To anyone who cares, I solved the problem: I didn't read with attention the error message and I didn't notice that the path C:\cygwin\tmp\scratch\mono-1.1.13.2\mcs\class\System\System.Net\HttpWebRequest.cs:480 that path doesn't exist on my machine and it ever has been. So, I threw away all my XDevelop file (apart from the .cs obviously), I rebuilt the project from scratch and everything it's okay now. I still can't understand why that path was in the X Develop solution and project file, but definitely was not a Mono problem At 09.28 01/02/2006, Ivano Luberti wrote: Hi to all, I'm using Mono 1.1.13.2 can someone give me a hint to understand why, tryin to consume a web service I get this error ? Unhandled Exception: System.NotImplementedException: The requested feature is not implemented. in [0x5] (at C:\cygwin\tmp\scratch\mono-1.1.13.2\mcs\class\System\System.Net\HttpWebRequest.cs:480) System.Net.HttpWebRequest:get_UnsafeAuthenticatedConnectionSharing () in (wrapper remoting-invoke-with-check) System.Net.HttpWebRequest:get_UnsafeAuthenticatedConnectionSharing () in <0x0010e> System.Web.Services.Protocols.HttpWebClientProtocol:GetWebRequest (System.Uri uri) in <0x00010> System.Web.Services.Protocols.SoapHttpClientProtocol:GetWebRequest (System.Uri uri) in <0x00050> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (System.String methodName, System.Object[] parameters) in [0x00014] (at D:\ivano\eclipse31\Egg\WebServiceClient\Web References\wslogon\Reference.cs:41) WebServiceClient.wslogon.LogOn:LogOnUser (System.String username, System.String password) in (wrapper remoting-invoke-with-check) WebServiceClient.wslogon.LogOn:LogOnUser (string,string) If I run the same code compiling it as a dll and running it under xsp I have no problem. But calling with "C:\Programmi\Mono-1.1.13.2\bin\mono.exe" --debug "D:\ivano\eclipse31\Egg\WebServiceClient\WebServiceClient.exe" I get this exception. Obviously using .NET framework works correctly. TIA == Archimede Informatica NEWS! == Realizzato il Sistema Integrato per la biglietteria della Torre di Pisa: prenotazione, vendita, pre-vendita ed emissione dei biglietti di ingresso alla Torre sia online che presso le biglietterie dislocate sulla piazza: http://www.opapisa.it/boxoffice Partner del Progetto Ci-Tel "Front office Telematico per il cittadino" Ente Coordinatore Comune di Pisa http://www.comune.pisa.it/doc/e-government.htm == dott. Ivano Mario Luberti Archimede Informatica societa' cooperativa a r. l. Sede Operativa Via Gereschi 36 - 56126- Pisa tel.: +39-050- 580959 tel/fax: +39-050-9711344 e-mail: [EMAIL PROTECTED] web: http://www.archicoop.it No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.375 / Virus Database: 267.14.25/247 - Release Date: 31/01/2006 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.1.375 / Virus Database: 267.14.25/247 - Release Date: 31/01/2006 == Archimede Informatica NEWS! == Realizzato il Sistema Integrato per la biglietteria della Torre di Pisa: prenotazione, vendita, pre-vendita ed emissione dei biglietti di ingresso alla Torre sia online che presso le biglietterie dislocate sulla piazza: http://www.opapisa.it/boxoffice Partner del Progetto Ci-Tel "Front office Telematico per il cittadino" Ente Coordinatore Comune di Pisa http://www.comune.pisa.it/doc/e-government.htm == dott. Ivano Mario Luberti Archimede Informatica societa' cooperativa a r. l. Sede Operativa Via Gereschi 36 - 56126- Pisa tel.: +39-050- 580959 tel/fax: +39-050-9711344 e-mail: [EMAIL PROTECTED] web: http://www.archicoop.it No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.375 / Virus Database: 267.15.0/249 - Release Date: 02/02/2006 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH for String.StartsWith(string, StringComparison)
On 02/03/06 Atsushi Eno wrote: > I agree on "faster" part, but considering the heaviness of string > comparison itself the difference is so trivial ;-) This is no excuse. If string comparison is slow, it needs to be made faster, not slower. String operations are _fundamental_ in many apps and every mono contributor needs to be aware of performance issues in such a core part. The code was ugly, so it's good to fix the style and it's possible to have nice code that's fast. In this particular case there is also one more consideration to make. The committed code is only marginally slower so most of the time it wouldn't be a big deal. But the other property of the original version is that the JIT will be able to optimize it away when the method is called with a constant StringComparison value, which happens most of the time. This is much more difficult with the committed version. 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] PATCH for String.StartsWith(string, StringComparison)
On 02/03/06 Paolo Molaro wrote: > The committed code is only marginally slower so most of the time it > wouldn't be a big deal. But the other property of the original version > is that the JIT will be able to optimize it away when the method is > called with a constant StringComparison value, which happens most of > the time. This is much more difficult with the committed version. I committed the change. In the future we should also probably have a static readonly invariantcompareinfo to avoid doing too many lookups. And of course the same in a thread local for the current culture. 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] The State Of Mono Assembly Verification?
On 02/02/06 Jim Purbrick wrote: > > mono_method_verify () has been superseded by > > verification during JIT time. > > When JIT time verification is failed is there an > exception thrown that an embedding app can use to take > appropriate action? Yes, this is a trivial change to make, I'll do it today. > Do you know exactly which checks are missing? I can There are many checks that need to be performed, it's not as simple as doing opcode checks as you seem to believe. The only way to know which are missing is to review all the code. Of course the review needs to be done independently by multiple people with the right skills and mindset (and time)... > What's the best way to set up this test suite? > Manually craft unverifiable assemblies for each > verification check and then test that Mono rejects > them? Well, since there are many possible attack ways, we also need many ways to test for them. First we need test cases for each opcode verification rule. These should be done with IL test programs. Note that we needs separate tests for invalid IL code and unverifiable IL code: they are two completely different things. Then we need to test for metdata issues: some things can be done again with IL sources, but many will be rejected by ilasm or by the underlying library PEAPI. We need to investigate if it's better to change ilasm to produce the incorrect assemblies (when given a specific command line option) or write a specific front-end to PEAPI or Cecil that can be used to create broken assemblies. Last, we need a crashme-like tool: the tool will randomly change bytes in some correct assembly and the assembly is fed to the jit. The jit must deal with the possible errors generated without crashing. Note that, while the assembly corruption can and needs to be automated, the jit behaviour can only be partially automatically monitored. A change could be made that doesn't affect the jit, but which should be detected... I'm sure Sebastien can offer more advice for the testing, too. 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] The State Of Mono Assembly Verification?
On Feb 3, 2006, at 11:29 AM, Paolo Molaro wrote: We need to investigate if it's better to change ilasm to produce the incorrect assemblies (when given a specific command line option) or write a specific front-end to PEAPI or Cecil that can be used to create broken assemblies. I don't know much about PEAPI, but Cecil does basically no verification and is a good candidate to emit broken assemblies. Jb ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] The State Of Mono Assembly Verification?
On 02/02/06 Miguel de Icaza wrote: > > IMHO, verification should be kept separate from the JIT. The job of the > > JIT is > > to generate machine code _fast_, while the goal of the verifier is to > > be _secure_. > > Mixing the two would probably lead to a JIT which wasn't very fast, and it > > wasn't very secure either. 'We are missing some checks' is a far cry > > from security. > > What about this plan: > > * Introduce an API in the runtime that verifies an assembly. > > * The API can be invoked from a tool, we already have pedump > --verify. > > * This API could be exposed to those that do not want to call > an external process to verify. We already have all that, what is missing is interest from contributors to fix/finish the implementation (or time for us inside Novell to do it). At first I implemented the current external verifier, mostly to help with the development of mcs;-), so you guys could check that the compiler produced valid code. I had planned to use the same verifier inside the jit, to avoid duplication of code. The issue is that the jit has different needs. The JIT needs to be able to execute also non-verifiable code, but it can also avoid some checks which would be expensive. So using the external verifier was more of a burden and it would slow down compilation too much. The JIT needs to check for valid IL code always and it needs to do it while converting IL code to the internal representation, because it needs to change the IR (typically by inserting instructions etc.). So the JIT can't be done without it's own IL code checks, having an external verifier is usless for the JIT viewpoint (consider also the needs to verify and validate Re.Emit code in memory). Now, we have two needs: 1) validation and verification at JIT time 2) offline validation and verification Now, point 1 is always needed and it needs to be implemented mostly inside the jit (metadata checks can be external and shared with 2). Having limited time, I didn't work anymore on 2 (metadata/verify.c), because 1 can always be used to implement at least the most useful subset of 2. If contributors are willing to work on 2, it's fine, but that won't help much with the security of the mono runtime, which is what people ultimately want, IMHO. 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] The State Of Mono Assembly Verification?
> I don't know much about PEAPI, but Cecil does basically no > verification and is a good candidate to emit broken assemblies. > > Jb Same is the case for PEAPI, no verification is done. ilasm also does almost no verification. -Ankit ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] The State Of Mono Assembly Verification?
On 02/02/06 Sebastien Pouliot wrote: > Can this be re-phrased as "can't have maximum performance with all > security checks" ? as I believe we *could* have a fast (but not as fast > as it could be) JIT with all checks - just like MS has (at least if we > had the same resources ;-). Change to: "with all the necessary checks". An external verifier can check for much more things that are not strictly required for the security of the system. So we can have a fast jit with all the necessary checks (please also note that the jit needs to do many of the checks anyway and it needs to do them inside jit code, because they lead to different generated code). And people can have an external verifier if they contribute it with more checks. The JIT verifier has much higher priority than the external one, IMHO. 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] The State Of Mono Assembly Verification?
On 02/02/06 Sebastien Pouliot wrote: [...] Excellent mail Sebastien. Just giving a summary for lazy people. *) We have plans to make mono execute untrusted code. *) The more contributions we get in this area, the faster we'll reach our common goal. *) Security is tricky, 1 single bug is enough to have no-security whatsoever. *) If someone waits for the complete secure code before contributing, he won't have any code to contribute, so better start sooner:-) *) We won't give any warranty until the code is complete and an audit has been done by multiple people with no bugs found. *) If you need an assurance for a subset of tests, we could give it, just remember that this doesn't make the complete test case secure. Example: we can guarantee that a subset of IL code is safe to execute, this is not hard and can be done in relatively short time. What matters if this IL subset if sufficient for your needs and that this doesn'ìt imply that things outside the IL code (such as the metadata etc are safe). 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] Utilizing the C# Parser
Hey, I want to use the mono C# Parser to get information about class stucture etc. in a project. You don't need to parse C# for "information about class structure etc." if "etc." doesn't contain code metrics and if the source code you want to introspect is compilable. It's far easier to use System.Reflection for that. Some code metrics can be obtained from IL as well. Have a look at http://www.mono-project.com/Gendarme http://www.mono-project.com/Cecil Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Utilizing the C# Parser
The mcs C# parser is optimized to compilation, so it won't give you all the information you would want, instead it would give you a "pre-compilation" tree where somethings where already changed to optimize the compilation etc... If you whish to get only the namespaces, classes, methods, etc... but nothing about the code inside the methods, etc... I would suggest you to use System.Reflection and/or Cecil. From here it seems there will be a problem - you only have source code and you don't need an assembly - so if you're sure the source code is compilable you can use CodeDOM to build it on-the-fly and then apply Reflection to that. If you need to get information about method/properties code and/or line numbers/columns for the code, then I would suggest you to look at some of the parsers avaible out there. Your best bet would be the MonoDevelop parser. Another try would be to search for some parser generators (cocoa, grammatica, gold and antlr comes to mind) and do/change an existing C# grammar - the same applies to the MonoDevelop and mcs parsers where you can get their grammar and change to make it do whatever you need. On 2/3/06, Robert Jordan <[EMAIL PROTECTED]> wrote: Hey,> I want to use the mono C# Parser to get information about class stucture> etc. in a project.You don't need to parse C# for "information about class structure etc."if "etc." doesn't contain code metrics and if the source code you want to introspect is compilable. It's far easier to useSystem.Reflection for that.Some code metrics can be obtained from IL as well. Have a look athttp://www.mono-project.com/Gendarme http://www.mono-project.com/CecilRobert___Mono-devel-list mailing list Mono-devel-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-devel-list-- Alexandre Gomes, Portugal ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] The State Of Mono Assembly Verification?
On Fri, 2006-02-03 at 11:34 +0100, Jb Evain wrote: > On Feb 3, 2006, at 11:29 AM, Paolo Molaro wrote: > > > We need to investigate if it's better to change ilasm to produce > > the incorrect assemblies (when given a specific command > > line option) or write a specific front-end to PEAPI > > or Cecil that can be used to create broken assemblies. > > I don't know much about PEAPI, but Cecil does basically no > verification and is a good candidate to emit broken assemblies. Interesting - considering that both cases have their uses. Is it by design ? I.e. will it be true in one/2/3... years or do you (or someone else ;-) plan to contributes (some of) the checks ? and if so do you plan to ensure they are always optional? -- Sebastien Pouliot <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] The State Of Mono Assembly Verification?
Hello Ankit, On Fri, 2006-02-03 at 03:57 -0700, Jain Ankit wrote: > > I don't know much about PEAPI, but Cecil does basically no > > verification and is a good candidate to emit broken assemblies. > > > > Jb > > Same is the case for PEAPI, no verification is done. Good to know. > ilasm also does almost no verification. In this particular case I'm hoping it's temporary ;-) Thanks for the information! -- Sebastien Pouliot <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] The State Of Mono Assembly Verification?
On Feb 3, 2006, at 2:14 PM, Sebastien Pouliot wrote: Interesting - considering that both cases have their uses. Is it by design ? I.e. will it be true in one/2/3... years or do you (or someone else ;-) plan to contributes (some of) the checks ? and if so do you plan to ensure they are always optional? There is no verification simply because I've not yet implemented them. It's in Cecil's TODO list. Cecil's design will allow you to implement easily (I hope :) all necessary checks an external verifier can perform. Of course, once the checks are implemented, they will be optionally run over the metadata at write time. Just like debugging data when it will be implemented ;) Jb ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Security spokesperson
Hello Christopher, On Fri, 2006-02-03 at 09:06 +0200, Christopher Bergström wrote: > [snip] > Sebastien Pouliot wrote: > > > > > I wish that security > >was more popular and btw I'm seeking contributors for creating a > >"security is cool" marketing campaign ;-) I admit I didn't expect any answers but it's... > [snip] > > Need a spokesperson for this? Let me be first in line. ... really cool :-) > Another developer and I have started working on a custom patchset for > our hardened box that still allows Mono to run, but IMHO a bit more secure. > > What's the first step? Some documentation? Like a Tips & Tricks/Best > practices page? Caveats because of missing code.. There's probably more but an article on the wiki (or linked from the wiki) would be nice start. > IRC channel? > #mono-security ? I'm on both #mono and #monodev but if people thinks it would be easier to talk about security elsewhere I don't have any issue participating in a #mono-security channel. > I've got a hit-list I've started to research and work > on from my end. Please share your interests :) > I'd be excited to get this off the ground. Thanks -- Sebastien Pouliot <[EMAIL PROTECTED]> Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Security spokesperson
Hello Christopher, That's great news! I've obviously been spending quite a bit of time rummaging around in Mono and ECMA-335 III,1.8 and will help out as much as I can! Cheers, Jim. --- Sebastien Pouliot <[EMAIL PROTECTED]> wrote: > Hello Christopher, > > On Fri, 2006-02-03 at 09:06 +0200, Christopher > Bergström wrote: > > [snip] > > Sebastien Pouliot wrote: > > > > > > > > I wish that security > > >was more popular and btw I'm seeking contributors > for creating a > > >"security is cool" marketing campaign ;-) > > I admit I didn't expect any answers but it's... > > > [snip] > > > > Need a spokesperson for this? Let me be first in > line. > > ... really cool :-) > > > Another developer and I have started working on a > custom patchset for > > our hardened box that still allows Mono to run, > but IMHO a bit more secure. > > > > What's the first step? Some documentation? Like a > Tips & Tricks/Best > > practices page? Caveats because of missing code.. > > > There's probably more but an article on the wiki (or > linked from the > wiki) would be nice start. > > > IRC channel? > > #mono-security ? > > I'm on both #mono and #monodev but if people thinks > it would be easier > to talk about security elsewhere I don't have any > issue participating in > a #mono-security channel. > > > I've got a hit-list I've started to research and > work > > on from my end. > > Please share your interests :) > > > I'd be excited to get this off the ground. > > Thanks > -- > Sebastien Pouliot <[EMAIL PROTECTED]> > Blog: http://pages.infinit.net/ctech/ > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Does your mail provider give you FREE antivirus protection? Get Yahoo! Mail http://uk.mail.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Controls in HTML comment block behave different in .Net and Mono
MS.Net is always the right behaviour, even if unlogic or buggy. I guess thats the mono ASP.Net parser ignoring everything placed between comments... seems like the behaviour should be process it but don't show it.
On 2/5/06, Arnhoffer Károly <[EMAIL PROTECTED]> wrote:
Hi,When I have an ASP.Net control in an HTML comment block of an aspx page it does not compile under Mono but it does compile under .Net.Exmple aspx:<%@ Page language="c#" Codebehind="
WebForm1.aspx.cs" AutoEventWireup="false" Inherits="MonoCharsetTest.WebForm1" %>
WebForm1
http://schemas.microsoft.com/intellisense/ie5">
Example cs:using System;using System.Collections;using System.ComponentModel;using System.Data;using System.Drawing
;using System.Web;using System.Web.SessionState;using System.Web.UI;using System.Web.UI.WebControls;using System.Web.UI.HtmlControls;namespace MonoCharsetTest{///
/// Summary description for WebForm1./// public class WebForm1 : System.Web.UI.Page{protected System.Web.UI.HtmlControls.HtmlInputButton Button1;
private void Page_Load(object sender, System.EventArgs e){// Put user code to initialize the page hereButton1.Value="Hello";
}#region Web Form Designer generated codeoverride protected void OnInit(EventArgs e){//// CODEGEN: This call is required by the
ASP.NET Web Form Designer.//InitializeComponent();base.OnInit(e);}///
/// Required method for Designer support - do not modify/// the contents of this method with the code editor./// private void InitializeComponent()
{this.Load += new System.EventHandler(this.Page_Load);}#endregion}}Results when running on mono:
Server error in '/c' applicationDescription: Error processing request.Error Message: HTTP 500.Stack Trace: System.NullReferenceException
: Object reference not set to an instance of an objectin <0x00012> MonoCharsetTest.WebForm1:Page_Load (System.Object sender, System.EventArgs e)in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs
(object,System.EventArgs)in <0x00117> System.Web.UI.Control:OnLoad (System.EventArgs e)in <0x000e5> System.Web.UI.Control:LoadRecursive ()in <0x0011e> System.Web.UI.Page:InternalProcessRequest
()in <0x000a4> System.Web.UI.Page:ProcessRequest (System.Web.HttpContext context)With .Net I get a page without the button and no compilation error.Wich is the right behaviour?VS.Net project, Mono and .Net results are attached.
Thanks!Károly___Mono-devel-list mailing listMono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list-- Alexandre Gomes, Portugal
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Controls in HTML comment block behave different in .Net and Mono
Alexandre Miguel Pedro Gomes wrote: MS.Net is always the right behaviour, even if unlogic or buggy. I guess thats the mono ASP.Net parser ignoring everything placed between comments... seems like the behaviour should be process it but don't show it. It makes sense how MS.NET deals with comments. For example, a web page designer which doesn't code herself, should be able to comment out parts of the aspx file. It it also usual (at some level) to generate HTML within comments (debugging output, preprocessing instructions for proxies, etc). Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Utilizing the C# Parser
Hello, > The mcs C# parser is optimized to compilation, so it won't give you > all the information you would want, instead it would give you a > "pre-compilation" tree where somethings where already changed to > optimize the compilation etc... This is true, but only to a very small extent. The parsing stage does very few transformations on the input data (like introducing implicit blocks for variable declarations) but other than that it should be pretty much what he wants. Now, the reality is that MCS is not a library, and we do not make any kind of guarantees about is API stability, and its also licensed under the GPL which might be a problem if used in a commercial product. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mod_mono/xsp
Hello, > I have been building mono through svn and this week i've noticed some > changes done in the System.Web directory. The build I did this morning > broke my web applications. I've checked the logs(access and error), > nothing there. When I browse my aspx pages, it seems like Apache is > stalled, normal html/php pages are being served tho. > > I just reverted back to xps/mod_mono 1.1.13 and everything worked again. There was a bug that lasted for about 36 hours in the compiler that broke a lot of code using iterators, xsp was affected. Could you try again? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Controls in HTML comment block behave different in .Net and Mono
You may have fallen foul of the same thing I did:
Codebehind="WebForm1.aspx.cs"
is a Visual Studio thing, apparently. You want to replace "CodeBehind"
with "Src".
It worked for me, anyway.
Cheers
Peter
Arnhoffer Károly wrote:
Hi,
When I have an ASP.Net control in an HTML comment block of an aspx page it does not compile under Mono but it does compile under .Net.
Exmple aspx:
<%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="MonoCharsetTest.WebForm1" %>
WebForm1
"http://schemas.microsoft.com/intellisense/ie5">
Example cs:
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Web;
using System.Web.SessionState;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;
namespace MonoCharsetTest
{
///
/// Summary description for WebForm1.
///
public class WebForm1 : System.Web.UI.Page
{
protected System.Web.UI.HtmlControls.HtmlInputButton Button1;
private void Page_Load(object sender, System.EventArgs e)
{
// Put user code to initialize the page here
Button1.Value="Hello";
}
#region Web Form Designer generated code
override protected void OnInit(EventArgs e)
{
//
// CODEGEN: This call is required by the ASP.NET Web Form Designer.
//
InitializeComponent();
base.OnInit(e);
}
///
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
///
private void InitializeComponent()
{
this.Load += new System.EventHandler(this.Page_Load);
}
#endregion
}
}
Results when running on mono:
Server error in '/c' application
Description: Error processing request.
Error Message: HTTP 500.
Stack Trace: System.NullReferenceException: Object reference not set to an instance of an object
in <0x00012> MonoCharsetTest.WebForm1:Page_Load (System.Object sender, System.EventArgs e)
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs)
in <0x00117> System.Web.UI.Control:OnLoad (System.EventArgs e)
in <0x000e5> System.Web.UI.Control:LoadRecursive ()
in <0x0011e> System.Web.UI.Page:InternalProcessRequest ()
in <0x000a4> System.Web.UI.Page:ProcessRequest (System.Web.HttpContext context)
With .Net I get a page without the button and no compilation error.
Wich is the right behaviour?
VS.Net project, Mono and .Net results are attached.
Thanks!
Károly
WebForm1
Error 500
Server error in '/c' application
Description: Error processing request.
Error Message: HTTP 500.
Stack Trace:
System.NullReferenceException: Object reference not set to an instance of an object
in <0x00012> MonoCharsetTest.WebForm1:Page_Load (System.Object sender, System.EventArgs e)
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs)
in <0x00117> System.Web.UI.Control:OnLoad (System.EventArgs e)
in <0x000e5> System.Web.UI.Control:LoadRecursive ()
in <0x0011e> System.Web.UI.Page:InternalProcessRequest ()
in <0x000a4> System.Web.UI.Page:ProcessRequest (System.Web.HttpContext context)
System.NullReferenceException: Object reference not set to an instance of an object
in <0x00012> MonoCharsetTest.WebForm1:Page_Load (System.Object sender, System.EventArgs e)
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs)
in <0x00117> System.Web.UI.Control:OnLoad (System.EventArgs e)
in <0x000e5> System.Web.UI.Control:LoadRecursive ()
in <0x0011e> System.Web.UI.Page:InternalProcessRequest ()
in <0x000a4> System.Web.UI.Page:ProcessRequest (System.Web.HttpContext context)--- End of inner exception stack trace ---
-->
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] mod_mono/xsp
Just did another svn build like 5 minutes ago, it's now working again. thanks dude. > Original Message > Subject: Re: [Mono-dev] mod_mono/xsp > From: Miguel de Icaza <[EMAIL PROTECTED]> > Date: Fri, February 03, 2006 11:21 am > To: Jonel Rienton <[EMAIL PROTECTED]> > Cc: mono-devel-list@lists.ximian.com > > Hello, > > > I have been building mono through svn and this week i've noticed some > > changes done in the System.Web directory. The build I did this morning > > broke my web applications. I've checked the logs(access and error), > > nothing there. When I browse my aspx pages, it seems like Apache is > > stalled, normal html/php pages are being served tho. > > > > I just reverted back to xps/mod_mono 1.1.13 and everything worked again. > > There was a bug that lasted for about 36 hours in the compiler that > broke a lot of code using iterators, xsp was affected. > > Could you try again? > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH for BitArray serialization compatibility with MS.
Hi, To support serialization between Mono and MS, I changed the member names of the BitArray class to reflect the names used by MS. Can somebody review and commit this patch? Thanks Sebastien BitArray.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Emailing: Scale.diff
Hi, Here's a patch for bug #77410. (SybaseParameter,Scale throws an InvalidCastException) Regards Sébas Scale.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Utilizing the C# Parser
Hi
> if you whish to get only the namespaces, classes, methods, etc... but
> nothing about the code inside the methods, etc... I would suggest you to
use
> System.Reflection and/or Cecil
unfortuenately reflection is not an option because I can not gurantee that
the source code is compileable. I want i.e. takr file xy.cs and get the
structure of it independently if the file depends on some other Classes or
not.
I mean you can parse i.e
MyType func() {}
without knowing what MyType exactly is (which I need to create an assembly).
> Now, the reality is that MCS is not a library, and we do not make any
> kind of guarantees about is API stability, and its also licensed under
> the GPL which might be a problem if used in a commercial product.
GPL is not a problem at all but I simply dont get it work at the moment.
@Monodevelop Parser
You are taling about the
Core\src\MonoDevelop.Projects\MonoDevelop.Projects.Parser
and the
Extras\CSharpBinding\Parser
classes right?
I only took a glance at it but it looks promising.
I saw that these Parser classes depends for example on the Project
class but as long I am not using any of the gtk# gui I should have
no probs get it running on windows too. right?
thx
Lukas
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Utilizing the C# Parser
I don't think any of it depends on GTK#. If I remeber well it doesn't depend on the Project either. Since you don't want to resolve the elements and things like that you want to check monodevelop/Core/src/ICSharpCode.SharpRefactory and not Extras\CSharpBinding\Parser.
The difference is that the CSharpBinding use ICSharpCode.SharpRefactory to parse the documents and then "translate" it into Monodevelop AST tree (a generic one so we can handle multiple languages) and resolve the items like the types and namespaces. So, the bindings do use the Project class and its friends so it can make the resolving.
So, use the ICSharp(...) and check the (...)Bindings to know how to use it properly.A side note: the ICSharpCode.SharpRefactory is GPL and comes from the SharpDevelop project. I'm not sure, but SharpDevelop2 is beta right now and it changed the license to LGPL... so seems a better choise, specially if they already support C#
2.0 (aka generics and stuff like that :)).On 2/3/06, lukas einkemmer <[EMAIL PROTECTED]> wrote:
Hi> if you whish to get only the namespaces, classes, methods, etc... but
> nothing about the code inside the methods, etc... I would suggest you touse> System.Reflection and/or Cecilunfortuenately reflection is not an option because I can not gurantee thatthe source code is compileable. I want
i.e. takr file xy.cs and get thestructure of it independently if the file depends on some other Classes ornot.I mean you can parse i.eMyType func() {}without knowing what MyType exactly is (which I need to create an assembly).
> Now, the reality is that MCS is not a library, and we do not make any> kind of guarantees about is API stability, and its also licensed under> the GPL which might be a problem if used in a commercial product.
GPL is not a problem at all but I simply dont get it work at the moment.@Monodevelop ParserYou are taling about theCore\src\MonoDevelop.Projects\MonoDevelop.Projects.Parserand theExtras\CSharpBinding\Parser
classes right?I only took a glance at it but it looks promising.I saw that these Parser classes depends for example on the Projectclass but as long I am not using any of the gtk# gui I should haveno probs get it running on windows too. right?
thxLukas--Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
___Mono-devel-list mailing listMono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list-- Alexandre Gomes, Portugal
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
