[Mono-dev] [PATCH] Fix auth tickets not expiring in ASP.NET (Bug 80739)
Hello, Attached is a diff that fixes the issue metioned in http://bugzilla.ximian.com/show_bug.cgi?id=80739. Please review, thanks marek Index: System.Web.Security/FormsAuthenticationModule.cs === --- System.Web.Security/FormsAuthenticationModule.cs (revision 72371) +++ System.Web.Security/FormsAuthenticationModule.cs (working copy) @@ -125,7 +125,7 @@ // incorrect cookie value, suppress the exception return; } - if (ticket == null || (ticket.IsPersistent ticket.Expired)) + if (ticket == null || (!ticket.IsPersistent ticket.Expired)) return; FormsAuthenticationTicket oldticket = ticket; signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Security on Compat Framework
I'm fairly certain it does, but this is not my particular field so I can't answer with authority. --Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthijs ter Woord Sent: 06 February 2007 08:00 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono.Security on Compat Framework Does it contain an SSL implementation too? Neil Cowburn wrote: The company I work for, OpenNETCF, already did a port of the System.Security.Cryptography namespace for .NET Compact Framework v1.0. CF v2.0 has a fairly comprehensive implementation OTB, so we removed it from our product, but you can still get the source for the CF v1.0 implementation from our site. We needed S.S.C for our WSE implementation. Go to smartdeviceframework.com and the version you are looking for is Smart Device Framework 1.4. --Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthijs ter Woord Sent: 05 February 2007 16:23 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono.Security on Compat Framework Hi Sebastien, I think my changes consist of the following: 1. A compatibility layer. This contains a rough copy of some namespaces from mono (S.IO, S.Security.Cryptography, S.ComponentModel, S.Diagnostics, S.Net, S.Runtime.ConstrainedExecution, S.Security, S.Threading) 2. The addition of a utility class which lets one launch a method asynchronously (ie, different thread), and the usage of this method wherever neccessary. Let me know if you're interested... Regards, Matthijs ter Woord Sebastien Pouliot wrote: Hello Matthijs, On Mon, 2007-02-05 at 17:04 +0100, Matthijs ter Woord wrote: Hi, For some private project, we've been trying to get Mono.Security running on the Compact .NET Framework. After we spend some ours of debugging, the major problem with it was that CF.NET seems to be lacking decent async method invocation support. Once we fixed that, the only thing we needed to do was copy some other parts of mono (mostly System.Security.Cryptography related) into the assembly. After this journey, I'd like to see whether there's any interest of getting these changes back to the Mono repository. It would be easier to answer if the patch was attached ;-) My guess is that some would be better inside Mono.Security and some outside(*)... This should probably be in a different project, which contains all kinds of compatibility classes, to emulate the normal .NET framework, but this seems quite doable to me. That would be a useful project, i.e. having an assembly for CF to upgrade it's ability (up to running Mono.Security or other stuff). (*)We could look at hosting (parts of) your changes into Crimson too. I hope to gain some comments on this... Regards, Matthijs ter Woord ___ 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-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] WS stack.
Hi Daniel,
Daniel Lundqvist wrote:
Hi Atsushi,
mån 2007-02-05 klockan 15:14 +0900 skrev Atsushi Eno:
Hi Daniel,
Daniel Lundqvist wrote:
The issue here is that it always sends the oid and parentoid field
regardless of value of fieldSpecified.
I got a patch (against SVN) for it, don't know if it's correct but
solves the problem for me. So now it only sends oid and parentoid when
fieldSpecified is set to true. This was tested with 1.1.17.1 but the
problem is in SVN as well from what I can see.
Oh, cool. Can you please share the patch so that it could be fixed?
Of course, thought I attached it but I'll reattach it. The problem is
that XmlTypeMapMember::CheckOptionalValueType is never called and thus
the OPTIONAL bit in its flags field is never set (Which is then checked
in XmlSerializationWriterInterpreter::MemberHasValue).
Thanks :) However, now I tried your patch but it does not seem to
fix the issue. Do you have actual case that the patch indeed fix
the issue? I attached what I tried.
There are some other places (I think) that XmlTypeMapMember is
instanciated but I didn't add the call there, so this patch only fixes
my problem. Perhaps this call should be placed in a more appropiate
place, but I don't speak the XML/WS stack fluently enough to find where.
If your patch does not fix the case that I attached, then yes it is
likely to happen. I'd wait for your case and try to fix it.
2) When using wsdl2 from latest release of Mono I have the following issues:
1) When using properties for member access, and field is the same name
as a keyword it don't prefix the property name with @.
Hmm, it would be nice if you file a bug for it. It is kind of corner
case, but fixing it would be nicer.
Will do. Discovered another problem of the same kind. The parser that is
generated for the WS also have the same problem with types that is named
after keywords and object, so when Mono tries to compile it it
encounters a couple of syntax errors.
Thanks :)
2) It seems to generate each service binding twice. One with the normal
name and another with name1. I.i
[System.Web.Services.WebServiceBinding(Name=packetfront_becs,
Namespace=urn:packetfront_becs)]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute(code)]
public class packetfront_becs :
System.Web.Services.Protocols.SoapHttpClientProtocol {
snip
}
[System.Web.Services.WebServiceBinding(Name=packetfront_becs,
Namespace=urn:packetfront_becs)]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute(code)]
public class packetfront_becs1 :
System.Web.Services.Protocols.SoapHttpClientProtocol {
snip
}
Do you have test case for this as well? I tried it (from svn) but
it didn't happen. Though I remember this kind of duplicate results
from those days I was working on Sys.Web.Services in my private
branch. It was because of target protocol unawareness on processing
bindings.
Hmm.. ok. Do this mean that there is some error in the WSDL file? I can
send our WSDL file in private to you if you want to investigate it.
If you mean what I've experienced, then no, it was bugs in my code
that it produced proxy classes for both SOAP 1.1 and 1.2 profiles.
If you can send me the problematic WSDL, I'll check it :)
Btw is there a way to have the WS stack reuse same WebRequest object for
the duration of the program? As it is now it creates a new for
WebRequest now and then (after a short while of inactivity it seems) and
this a new TCP connection. I would like it to use HTTP/1.1 Keep-Alive to
cut down traffic and TCP connections (since my software is a fairly long
running CLI program that does 50k-100k SOAP calls). I tried overriding
GetWebRequest(Uri) on the generated WS proxy code to return a singleton
WebRequest but that only resulting in using a disposed object after a
short while.
I'm kind of newbie to this area, but according to the API I guess
it might be possible if you create your own SoapHttpClientProtocol
(derived) class that overrides GetWebRequest() where you return
the same WebRequest whose KeepAlive is enabled, and use replace
SoapHttpClientProtocol with your own class.
Atsushi Eno
using System;
using System.Web.Services;
using System.Web.Services.Protocols;
[WebService]
public class TestService
{
[WebMethod]
//[SoapRpcMethod]
public void Register (TestObject data)
{
}
}
/// remarks/
[System.Xml.Serialization.SoapType(Namespace=urn:packetfront_becs)]
public class TestObject {
/// remarks/
public System.UInt64 oid;
/// remarks/
[System.Xml.Serialization.SoapIgnore()]
public bool oidSpecified;
/// remarks/
public System.UInt64 parentoid;
/// remarks/
[System.Xml.Serialization.SoapIgnore()]
public bool parentoidSpecified;
/// remarks/
public string creator;
}
Re: [Mono-dev] Monodoc engine crashes um uncompressed help, stopping MD code completion
Miguel de Icaza wrote: Don't know what is best for monodoc's engine, to drop uncompressed support altogether or to correct the subclass to override the needed methods. Any bets? Drop uncompressed support. I did not even know we had that. This is my hack that underlies 'monodoc --edit path' right? I use that all the time to edit my own documentation, rather than using a text editor, so I'd rather you didn't drop it. I've never had that crash for me except for when monodocer left the index.xml file in an inconsistent state. -- - Josh Tauberer http://razor.occams.info Yields falsehood when preceded by its quotation! Yields falsehood when preceded by its quotation! Achilles to Tortoise (in Gödel, Escher, Bach by Douglas Hofstadter) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WS stack.
Hi :) Daniel Lundqvist wrote: Hey again :) ons 2007-02-07 klockan 20:51 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: Hi Atsushi, mån 2007-02-05 klockan 15:14 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: The issue here is that it always sends the oid and parentoid field regardless of value of fieldSpecified. I got a patch (against SVN) for it, don't know if it's correct but solves the problem for me. So now it only sends oid and parentoid when fieldSpecified is set to true. This was tested with 1.1.17.1 but the problem is in SVN as well from what I can see. Oh, cool. Can you please share the patch so that it could be fixed? Of course, thought I attached it but I'll reattach it. The problem is that XmlTypeMapMember::CheckOptionalValueType is never called and thus the OPTIONAL bit in its flags field is never set (Which is then checked in XmlSerializationWriterInterpreter::MemberHasValue). Thanks :) However, now I tried your patch but it does not seem to fix the issue. Do you have actual case that the patch indeed fix the issue? I attached what I tried. Weird. I've redone my tests with the 1.2.3 release. With a stock System.Xml.dll it have the problem but with a patched (with the patch I sent earlier) it don't. There are some other places (I think) that XmlTypeMapMember is instanciated but I didn't add the call there, so this patch only fixes my problem. Perhaps this call should be placed in a more appropiate place, but I don't speak the XML/WS stack fluently enough to find where. If your patch does not fix the case that I attached, then yes it is likely to happen. I'd wait for your case and try to fix it. Now I think I see one issue. Since you are using WebService and WebMethod attributes perhaps they are hitting the other path that is calling CreateMapMember(), in ImportMembersMapping in either XmlReflectionImport.cs or SoapReflectionImport.cs (depends on using literal encoding or not). After some more investigation that seems to be the case. From what I can see the enclosing type is not available at that point (which is needed to call XmlTypeMapMember::CheckOptionalValueType). Well, however removing [WebService] didn't change anything, and without [WebMethod] it doesn't expose any ports. Or are you checking anything else than the output WSDL? (As long as the WSDL contains 'oldSpecified' and 'parentoidSpecified' the issue isn't fixed.) Probably a reproducible example would tell me what exactly is the issue you are having fix. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Monodoc engine crashes um uncompressed help, stopping MD code completion
Joshua, It happens when some, probably newer, methods to extract pieces of xml are called and the base class assumes a zipfile is present. As I said, when MD is regenerating the code completion database it uses such functionality. If it is something to keep, probably some refactoring of the inheritance tree is in order, maybe spawning to middle classes for zipfile/ uncompressed families of leaf classes. Can't dig in it just now... Sorry On 2/7/07, Joshua Tauberer [EMAIL PROTECTED] wrote: Miguel de Icaza wrote: Don't know what is best for monodoc's engine, to drop uncompressed support altogether or to correct the subclass to override the needed methods. Any bets? Drop uncompressed support. I did not even know we had that. This is my hack that underlies 'monodoc --edit path' right? I use that all the time to edit my own documentation, rather than using a text editor, so I'd rather you didn't drop it. I've never had that crash for me except for when monodocer left the index.xml file in an inconsistent state. -- - Josh Tauberer http://razor.occams.info Yields falsehood when preceded by its quotation! Yields falsehood when preceded by its quotation! Achilles to Tortoise (in Gödel, Escher, Bach by Douglas Hofstadter) -- Rafael Monoman Teixeira --- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WS stack.
Hi, Ok, I think there perhaps is a missunderstanding here. What I'm talking about here is not the resulting WSDL but the actual SOAP/XML serialization of the RPC call. I apologize if I wasn't clear enough about that from the start. Hope that makes more sense for you in this case. -Ursprungligt meddelande- Från: [EMAIL PROTECTED] genom Atsushi Eno Skickat: on 2007-02-07 16:27 Till: mono-devel-list@lists.ximian.com Ämne: Re: [Mono-dev] WS stack. Hi :) Daniel Lundqvist wrote: Hey again :) ons 2007-02-07 klockan 20:51 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: Hi Atsushi, mån 2007-02-05 klockan 15:14 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: The issue here is that it always sends the oid and parentoid field regardless of value of fieldSpecified. I got a patch (against SVN) for it, don't know if it's correct but solves the problem for me. So now it only sends oid and parentoid when fieldSpecified is set to true. This was tested with 1.1.17.1 but the problem is in SVN as well from what I can see. Oh, cool. Can you please share the patch so that it could be fixed? Of course, thought I attached it but I'll reattach it. The problem is that XmlTypeMapMember::CheckOptionalValueType is never called and thus the OPTIONAL bit in its flags field is never set (Which is then checked in XmlSerializationWriterInterpreter::MemberHasValue). Thanks :) However, now I tried your patch but it does not seem to fix the issue. Do you have actual case that the patch indeed fix the issue? I attached what I tried. Weird. I've redone my tests with the 1.2.3 release. With a stock System.Xml.dll it have the problem but with a patched (with the patch I sent earlier) it don't. There are some other places (I think) that XmlTypeMapMember is instanciated but I didn't add the call there, so this patch only fixes my problem. Perhaps this call should be placed in a more appropiate place, but I don't speak the XML/WS stack fluently enough to find where. If your patch does not fix the case that I attached, then yes it is likely to happen. I'd wait for your case and try to fix it. Now I think I see one issue. Since you are using WebService and WebMethod attributes perhaps they are hitting the other path that is calling CreateMapMember(), in ImportMembersMapping in either XmlReflectionImport.cs or SoapReflectionImport.cs (depends on using literal encoding or not). After some more investigation that seems to be the case. From what I can see the enclosing type is not available at that point (which is needed to call XmlTypeMapMember::CheckOptionalValueType). Well, however removing [WebService] didn't change anything, and without [WebMethod] it doesn't expose any ports. Or are you checking anything else than the output WSDL? (As long as the WSDL contains 'oldSpecified' and 'parentoidSpecified' the issue isn't fixed.) Probably a reproducible example would tell me what exactly is the issue you are having fix. Atsushi Eno ___ 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] ASP.NET 2.0 - fix for TemplateSourceDirectory inheritance with master pages
Hello,
The attached diff fixes a situation, where ResolveClientUrl wouldn't work
correctly if it was used from within a control placed in a page that uses a
master page, i.e. if the parenthood tree was like:
System.Web.UI.WebControls.ContentPlaceHolder
System.Web.UI.HtmlControls.HtmlForm
ASP.test_master
ASP.Default_aspx
with the site layout:
Default.aspx
subdir/test.master
subdir/Default.aspx
In such situation, ResolveUrl (called by ResolveClientUrl) would return
incorrect URL for any relative address, in the above case, if invoked from
~/Default.aspx:
ResolveClientUrl(subdir/Default.aspx) == subdir/subdir/Default.aspx
This was due to the fact, that ASP.test_master TemplateSourceDirectory code
(generated by the TemplateControlCompiler) would not reach up to its parent,
but would return ~/subdir instead of /.
The diff makes two modifications - first it makes sure TemplateSourceDirectory
always returns a HTTP-absolute URL (e.g. /, /subdir etc) and that any template
control checks for its parent's TemplateSourceDir value before returning its
hard-coded source directory.
please review, thanks
marek
Index: System.Web.Compilation/TemplateControlCompiler.cs
===
--- System.Web.Compilation/TemplateControlCompiler.cs (revision 72459)
+++ System.Web.Compilation/TemplateControlCompiler.cs (working copy)
@@ -1417,7 +1417,37 @@
prop.Name = TemplateSourceDirectory;
prop.Attributes = MemberAttributes.Public | MemberAttributes.Override;
- CodePrimitiveExpression expr = new CodePrimitiveExpression (parser.BaseVirtualDir);
+ // if ((this.Parent != null))
+ // return this.Parent.TemplateSourceDirectory;
+ CodeFieldReferenceExpression parentField = new CodeFieldReferenceExpression ();
+ parentField.TargetObject = thisRef;
+ parentField.FieldName = Parent;
+
+ CodeFieldReferenceExpression tsdField = new CodeFieldReferenceExpression ();
+ tsdField.TargetObject = parentField;
+ tsdField.FieldName = TemplateSourceDirectory;
+
+ CodeMethodReturnStatement parentRet = new CodeMethodReturnStatement (tsdField);
+ CodeConditionStatement condStatement = new CodeConditionStatement (
+new CodeBinaryOperatorExpression (parentField,
+ CodeBinaryOperatorType.IdentityInequality,
+ new CodePrimitiveExpression (null)),
+parentRet);
+
+ prop.GetStatements.Add (condStatement);
+
+ string tsd, bvd = parser.BaseVirtualDir;
+ int len = bvd.Length;
+ if (len = 2 bvd [0] == '~') {
+if (bvd [1] == '/')
+tsd = bvd.Substring (1);
+else
+tsd = '/' + bvd.Substring (1);
+ } else if (len = 1 bvd [0] != '/')
+tsd = '/' + bvd;
+ else
+tsd = bvd;
+ CodePrimitiveExpression expr = new CodePrimitiveExpression (tsd);
prop.GetStatements.Add (new CodeMethodReturnStatement (expr));
mainClass.Members.Add (prop);
}
signature.asc
Description: PGP signature
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Almost certain this is a bug.
Hi, I have a VS.NET app. There are resx files in the base of the app folder and one in properties. I have used resgen to convert the resx files to resource files and compiled like this gmcs -r:System.Windows.Forms -r:System.Drawing -r:System.Data -res:Form1.resources -res:Form2.resources -res:AboutBox1.resources -res:Properties\Resources.resources *.cs Properties\*.cs -t:winexe code compiles fine. When I come to run it (either under Linux or Win32), I get the error that the resource file from Properties was not correctly embedded in the compiled app. I have a second app with 1 resx file in the root of the application. Again, convert using resgen and build. This time, the app works fine - and for other simple apps with the resx file in the root of the app folder it works without a hitch. Is anyone else seeing this problem or is it me? Using mono-1.2.3 under Win32 and Linux TTFN Paul -- MmmmShakira geschmiert mit schokolade sagt Homer signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Almost certain this is a bug.
AFAIK you need to pass: -res:Properties/Resources.resources using a 'forward-slash', and maybe adjusting the resource ID like: -res:Properties/Resources.resources,Resources.resources 'man mcs' gives more detail. :) On 2/7/07, Paul [EMAIL PROTECTED] wrote: Hi, I have a VS.NET app. There are resx files in the base of the app folder and one in properties. I have used resgen to convert the resx files to resource files and compiled like this gmcs -r:System.Windows.Forms -r:System.Drawing -r:System.Data -res:Form1.resources -res:Form2.resources -res:AboutBox1.resources -res:Properties\Resources.resources *.cs Properties\*.cs -t:winexe code compiles fine. When I come to run it (either under Linux or Win32), I get the error that the resource file from Properties was not correctly embedded in the compiled app. I have a second app with 1 resx file in the root of the application. Again, convert using resgen and build. This time, the app works fine - and for other simple apps with the resx file in the root of the app folder it works without a hitch. Is anyone else seeing this problem or is it me? Using mono-1.2.3 under Win32 and Linux TTFN Paul -- MmmmShakira geschmiert mit schokolade sagt Homer ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] ASP.NET 2.0 - fix page culture creation when the browser passes neutral culture
Hello,
The attached diff fixes a backtrace when the browser passes a culture of the
form 'en', 'de' - i.e. a neutral culture which cannot be used as the current
thread culture/ui culture. Please review, thanks
marek
Index: System.Web.UI/Page.cs
===
--- System.Web.UI/Page.cs (revision 72462)
+++ System.Web.UI/Page.cs (working copy)
@@ -710,14 +710,14 @@
string[] languages = Request.UserLanguages;
try {
if (languages != null languages.Length 0)
- ret = new CultureInfo (languages[0]);
+ ret = CultureInfo.CreateSpecificCulture (languages[0]);
} catch {
}
if (ret == null)
ret = deflt;
} else
- ret = new CultureInfo (culture);
+ ret = CultureInfo.CreateSpecificCulture (culture);
return ret;
}
signature.asc
Description: PGP signature
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] ASP.NET 2.0 - MS.NET compatibility fix for the app resource compiler
Hello,
The attached diff embeds all the resources compiled from App_GlobalResources
with the Resources. prefix - the same way MS.NET does. Please review, thanks
marek
Index: System.Web.Compilation/AppResourcesCompiler.cs
===
--- System.Web.Compilation/AppResourcesCompiler.cs (revision 72462)
+++ System.Web.Compilation/AppResourcesCompiler.cs (working copy)
@@ -86,6 +86,7 @@
App_GlobalResources,
dll,
OnCreateRandomFile) as string;
+
if (assemblyPath == null)
throw new ApplicationException (Failed to create global resources assembly);
@@ -365,6 +366,7 @@
classname = nsname;
nsname = Resources;
} else {
+if (!nsname.StartsWith (Resources, StringComparison.InvariantCulture))
nsname = String.Format (Resources.{0}, nsname);
classname = classname.Substring(1);
}
@@ -526,7 +528,7 @@
{
string path = arfi.Info.FullName;
string resource = Path.Combine (TempDirectory,
- Path.GetFileNameWithoutExtension (path) + .resources);
+ Resources. + Path.GetFileNameWithoutExtension (path) + .resources);
FileStream source = null, destination = null;
IResourceReader reader = null;
ResourceWriter writer = null;
Index: System.Web.Compilation/ResourceExpressionBuilder.cs
===
--- System.Web.Compilation/ResourceExpressionBuilder.cs (revision 72462)
+++ System.Web.Compilation/ResourceExpressionBuilder.cs (working copy)
@@ -48,7 +48,7 @@
public override object EvaluateExpression (object target, BoundPropertyEntry entry, object parsedData, ExpressionBuilderContext context)
{
ResourceExpressionFields fields = parsedData as ResourceExpressionFields;
- return HttpContext.GetGlobalResourceObject (fields.ClassKey, fields.ResourceKey);
+ return HttpContext.GetGlobalResourceObject (Resources. + fields.ClassKey, fields.ResourceKey);
}
public override CodeExpression GetCodeExpression (BoundPropertyEntry entry, object parsedData, ExpressionBuilderContext context)
@@ -57,7 +57,7 @@
return new CodeMethodInvokeExpression (
new CodeThisReferenceExpression (),
GetGlobalResourceObject,
-new CodeExpression [] { new CodePrimitiveExpression (fields.ClassKey),
+new CodeExpression [] { new CodePrimitiveExpression (Resources. + fields.ClassKey),
new CodePrimitiveExpression (fields.ResourceKey) });
}
signature.asc
Description: PGP signature
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] ASP.NET 2.0 - avoid duplicate control registration exception
Hello,
The attached fiff fixes an issue when a control is registered from within
Web.config and then re-registered using the %@ Register % directive. Please
review, thanks
marek
Index: System.Web.Compilation/AspComponentFoundry.cs
===
--- System.Web.Compilation/AspComponentFoundry.cs (revision 72462)
+++ System.Web.Compilation/AspComponentFoundry.cs (working copy)
@@ -179,6 +179,10 @@
#if NET_2_0
string source;
+ public bool FromWebConfig {
+get { return source != null; }
+ }
+
public TagNameFoundry (string tagName, string source)
{
this.tagName = tagName;
@@ -282,6 +286,10 @@
TagNameFoundry tn = (TagNameFoundry) foundry;
string tagName = tn.TagName;
if (tagnames.Contains (tagName)) {
+#if NET_2_0
+ if (tn.FromWebConfig)
+ return;
+#endif
string msg = String.Format ({0}:{1} already registered., tagPrefix, tagName);
throw new ApplicationException (msg);
}
signature.asc
Description: PGP signature
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
