why are you compiling on the fly the embedded VB.net code (or the code-behind class source if you support codebehind already in mono's ASP.net)?

.NET has a on-the-fly compilation feature for ASP.net, but the default is to use precompiled .DLLs (to IL) and upon first use of those DLLs they're converted to native code and cached

-----
George Birbilis ([EMAIL PROTECTED])
http://www.kagi.com/birbilis
--------------
----- Original Message ----- From: "Jambunathan Jambunathan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, October 13, 2004 11:53 AM
Subject: Re: [Mono-list] Language Clarification



mbas is awfully slow right now (fair enough considering that mbas is
an
alpha code) and is tortoise when compared to mcs. So this is one
reason
why a page coded in VB has some trouble being rendered.

As an afterthought, if you really need to see your VB.NET coded ASP page running modified, try bumping the executionTimeout in either machine.config (located in prefix/etc/mono/1.0) or your app's Web.Config.

This will atleast give us the infomration that whether or not a
particular
VB.NET page works.

That aside, if anyone wants to see the actual *.vb file generated by
XSP server, then they can set the following environmnet variable.

export MONO_ASPNET_NODELETE = 1.

The temporary files can be located under /tmp.

Regards,
Jambunathan K.






"David P. Donahue" <[EMAIL PROTECTED]> 10/12/04 8:50 PM >>>
I realize that Mono focuses its development on C# as a whole, but I'm
wondering something about other languages in general.  I'm no expert
on
the core of .NET, but I was under the impression that one of its
features is that code from any .NET language, when compiled, becomes a
single common language for any .NET interpreter (such as Mono) to use.
That is, if I write something in VB and compile it in Visual Studio,
the
end result is no different (not critically different, anyway) from the
end result that would be achieved had I used C# or any other .NET
language.  Is this the case?

If so, then I'm unclear on a problem that I've been having (and have
been receiving very help assistance on, thanks to this mailing list)
in
trying to get an ASP .NET web application written in VB to work on
Mono.

I was told of a work-around to get my first test page to work, which
was
to set the page language to C# even though my code-behind was all in
VB.
This worked... for that small test page (which consisted of a button
which, when pressed, changed a property on a label).  My next test was
to use a DataGrid and grab a table from a database.  This page is
slightly more complex as a test, since it has more functions in the
code-behind and has some VB code in the design of the .aspx file
itself.
The aforementioned work-around doesn't seem to extend this far, as
setting my page language to C# now results in a vague "object
reference
not set to an instance of an object" error (with no obvious mention of
the object in question).  And, of course, setting it back to VB
results
in a "thread was being aborted" error that caused the need for the
aforementioned work-around.

If my originally mentioned impression of how .NET works is correct,
why
is there a difference between the two at all?  When I compile my
"solution" in Visual Studio, isn't the resulting .dll in the bin
folder
contain all that Mono needs?  If so, is my method of compilation not
accomplishing this properly?

For reference, I am using the following setup:
Development:
 Windows XP, .NET Framework 1.1.4322, Visual Studio .NET 2003
(7.1.3088)
Production:
 Slackware 10.0, Linux 2.4.26, Mono 1.1.1 (mod_mono with Apache
1.3.31)



Regards,
David P. Donahue
[EMAIL PROTECTED]

_______________________________________________
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
_______________________________________________
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list

Reply via email to