CodeDom instead of scripting?
Messages   Related Types
This message was discovered on microsoft.public.dotnet.framework.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
Post a new message to this list...

Christoph Nahr
The usual method to add programmability to a program is to define a
scripting interface. Now that we have .NET I was wondering if one
could use the CodeDom classes for the same purpose? In other words,
can I use CodeDom (or perhaps another .NET class) to let users write
C# or VB.NET files on their machines and dynamically compile them at
runtime? The users would only have the .NET runtime, not the SDK.
Needless to say that would be pretty cool but I suspect there's a
problem because the SDK is 130 MB and the runtime only 20 MB...
Reply to this message...
 
    
Kent Bowling
In order to do this, you would need to be able to parse
C# and VB.

The problem is Microsoft.CSharp.CSharpCodeProvider and
Microsoft.VisualBasic.VBCodeProvider ALWAYS return null
when you call CreateParser(). I've seen it confirmed in
one of the newsgroups by a MS employee.

-Kent

[Original message clipped]

Reply to this message...
 
    
Christoph Nahr
Thanks. I checked the older messages and saw the reply you mentioned.
So you'd first have to write your own C# or VB.NET compiler and plug
them into CodeDom... that's too bad but I suspected as much. Makes
the CodeDom kind of worthless right now except for compiler writers.
Guess it's back to ActiveX scripting them, or maybe embedding
scriptlets in my XML data files... hmm.

On Wed, 20 Mar 2002 11:25:13 -0800, "Kent Bowling"
<Click here to reveal e-mail address> wrote:

[Original message clipped]

Reply to this message...
 
    
Jay B. Harlow [MVP - Outlook] (VIP)
Christoph,
You do realize that using the CodeDom, you can get access to the Compiler,
feed it some C# or VB.NET code, and create an assemble out of it.

The CreateGenerator & CreateCompiler methods are implemented, it is just
that CreateParser that is not!

- Get a CSharpCodeProvider object
- Call CSharpCodeProvider.CreateCompiler
- Call ICodeCompiler.CompileAssemblyFromSource

I'm sure there are more steps... VB.NET works also...

I want to say I remember seeing an example, but I do not remember where...

Hope this helps
Jay

"Christoph Nahr" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...
 
    
Christoph Nahr
Thanks Jay, I eventually discovered the CreateCompiler method but
unfortunately all it does is call the command-line compilers (for C#
and VB.NET) so it's not much use for client-side scripting... but it
looks like I can get things done with JScript!

On Wed, 20 Mar 2002 21:28:18 -0600, "Jay B. Harlow [MVP - Outlook]"
<Click here to reveal e-mail address> wrote:

[Original message clipped]

Reply to this message...
 
    
Christoph Nahr
Here's an addendum to my previous reply, crossposted to
dotnet.scripting this time since it seems more appropriate.
I've experimented a bit and noticed a couple of things...

1. In addition to the VB and C# code providers, you can also use
Microsoft.JScript.JScriptCodeProvider for CodeDomProvider. It's not
listed under CodeDomProvider but it also derives from this class.

2. However, that doesn't help you much since -- you guessed it --
JScriptCodeProvider also returns null upon CreateParser...

3. However again, there's another code generation method named
CreateCompiler, and *this* method has a working implementation for all
three languages!

4. At this point I was ecstatic for about 15 minutes until I realised
that CreateCompiler simply calls the command-line compilers for C# and
VB.NET, making this method worthless for client-side scripting...

But there's one last chance... I didn't see the jsc startup message
for the JScript instantiation of CreateCompiler, so maybe this one is
actually an in-memory compiler? A temporary .js file had been created
for my source code string, though, so maybe I'm mistaken.

Anyone knows for sure how the JScript CreateCompiler method works?

On Wed, 20 Mar 2002 11:25:13 -0800, "Kent Bowling"
<Click here to reveal e-mail address> wrote:

[Original message clipped]

Reply to this message...
 
    
Peter Torr \(MS\) (VIP)
"Christoph Nahr" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Correct; JScript .NET implements these things so that it works with tools
like ASP .NET, WSDL, and XSD. They all generate CodeDOM trees, serialise
them to source code, and then compile them with a CodeDOM provider.

[Original message clipped]

Yup, as previously verified (I'm guessing the MS employee was me ;-) ) this
is a feature that was not implemented in v 1.0

[Original message clipped]

It's your lucky day!

The JScript implementation of CreateCompiler uses the JScript .NET VSA
engine to do the compilation. VSA is a scheme for in-memory compilation of
source code. VB also has a VSA implementation, but it's not used for
CreateCompiler (don't ask...). There is no VSA implementation for C# or any
other language.

The temporary JScript file is created because the consumers of
CodeDOMProvider assume that the compiler is disk based, and that it will
only work with files on disk. JScript .NET works with files on disk, or
strings of code in memory, but nobody else does. So, things like ASP .NET
write the file to disk, call the compiler to compile it, then throw it away.

If I knew what you were trying to do, I might be able to help some more ;-)

Peter

--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.

Reply to this message...
 
    
Christoph Nahr
On Wed, 20 Mar 2002 21:29:36 -0800, "Peter Torr \(MS\)"
<Click here to reveal e-mail address> wrote:

[Original message clipped]

Hmm... do you happen to know if the runtime will get built-in parsers
for C# and VB.NET in a future revision?

[Original message clipped]

Ah, fantastic! I'm vaguely aware of VSA, IIRC you have to buy this
super-expensive extra licence to get the VBA implementation, right?

[Original message clipped]

Thanks for the explanation! As it turns out I might not need the
CodeDomProvider class at all since JScript has such a nifty eval()
function (is this the same compiler as for compiling a string with
CompileAssemblyFromSource on a JScriptCodeProvider?).

What I'm trying to do is give users the ability to write small plug-in
scripts to alter or extend an application's functionality, basically
like using VBA but without buying the licence for VBA. :-) The
language isn't really important, I'm just trying to avoid the plumbing
associated with ActiveX scripting or hand-crafting a LUA interface.

PS: Before sending this post I experimented a bit more and eval()
works out great... I'm posting the results to a new thread.
Reply to this message...
 
    
Bruce Barker
as peter will tell you, vsa is free and included in the framework, unless
you want to use the IDE/debugger. The vsa IDE/debugger is seperate piece
that you license.

check the scripting clinic on msdn for more details and samples, but it does
what you want, and supports two languages jscript and vb.net. note - as you
were willing you try the codedom, try coding directly to the vsa engine, and
skip wrappers. i quick search for vsa on dejanews will do it.

"Christoph Nahr" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...
 
    
Christoph Nahr
Thanks, Bruce. I saw the "Script happens .NET" column in the
Scripting Clinic, though that seems to be the only article so far on
..NET and scripting (except for web-specific stuff). Am I correct in
assuming that Peter's VSA demos in his PDC2001 package (URL below)
does what you mean by "coding directly to the VSA engine?"

http://www.gotdotnet.com/userarea/filedetails.aspx?FileName=PDC2001.zip

On Thu, 21 Mar 2002 16:32:33 -0800, "Bruce Barker" <Click here to reveal e-mail address>
wrote:

[Original message clipped]

Reply to this message...
 
    
Bruce Barker
the vsa sdk come with some helper classes, and i think the one the scripting
clinic examples use them, but you'd be better off calling the engine
directly, as this gives better understanding of how they work.

note there are three engines

Microsoft.Vsa.VsaLoader // loads vsa
compiled binaries
Microsoft.VisualBasic.Vsa.VsaEngine // vb engine
Microsoft.JScript.Vsa.VsaEngine // jscript engine

"Christoph Nahr" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...
 
    
Christoph Nahr
Note to readers of this thread in microsoft.public.dotnet.framework:
I've posted a few examples of adding scripting for stand-alone .NET
applications over in microsoft.public.dotnet.scripting under thread
title "Tutorial: How to add scripting to a .NET program".
Reply to this message...
 
 
Microsoft.CSharp.CSharpCodeProvider
Microsoft.JScript.JScriptCodeProvider
Microsoft.JScript.Vsa.VsaEngine
Microsoft.VisualBasic.VBCodeProvider
Microsoft.VisualBasic.Vsa.VsaEngine
Microsoft.Vsa.VsaLoader
System.CodeDom.Compiler.CodeDomProvider
System.CodeDom.Compiler.ICodeCompiler




Ad
MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT
 
 Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com