In all the info from MS, I can't seem to find a solid answer to this
question. I want to develop an application such that I can essentially
define a UI once and have it available as both a windows forms application
and ASP.NET application. I found one blurb somewhere that WPF applied to
both windows forms and web forms, but that was about it.

So, is it the case that I could define a UI form using XAML and have WPF use
that in the context of both windows forms application and ASP.NET?

Daniel Billingsley wrote:

> In all the info from MS, I can't seem to find a solid answer to this
> question. I want to develop an application such that I can
> essentially define a UI once and have it available as both a windows
> forms application and ASP.NET application. I found one blurb
> somewhere that WPF applied to both windows forms and web forms, but
> that was about it.
>
> So, is it the case that I could define a UI form using XAML and have
> WPF use that in the context of both windows forms application and
> ASP.NET?

The answer is: depends on what features you're using.

There's two forms of WPF for the web: loose XAML and XBAP applications[1].
Loose XAML would pretty much be used to create pretty pictures and animations.
There's no code behind and you're limited to a sandboxed set of components[2]
you can work with. Then there's XBAP applications. These, like loose XAML,
will run in a sandbox, but can also have compiled code-behind. The code-behind
can do anything with .NET that is possible in the Interet Zone. Note that
you can also request higher levels of trust for an XBAP application[3].

All said, you should easily be able share resources between these types of
application and the straight up windows application. Code, on the other hand,
will need to be zone aware.

HTH,
Drew

[1] http://windowssdk.msdn.microsoft.com...c6bb8900df.asp
[2] http://windowssdk.msdn.microsoft.com...0b1d032483.asp
[3] http://blogs.gotdotnet.com/karstenj/...29/498061.aspx

___________________________________
Drew Marsh
Chief Software Architect
Mimeo.com, Inc. - http://www.mimeo.com
Microsoft C# / WPF MVP
Weblog - http://blog.hackedbrain.com/

If I understand [1] correctly it's talking about essentially an easy way to
deploy xaml-based applciations that still run in the WPF context on the
client (and therefore require it on the client), which is something quite
different than an HTML-based web application. Is that correct?

It looks like I need to go a custom direction for what I want to accomplish,
but xaml could still be the basis for it.

I want to have one form layout definition that could be used in both windows
form and asp.net contexts. Most of the code-behind would be in base form
classes or otherwise implemented in a controller of some sort. So at the end
of the day the definition should really be just controls, their binding to
the underlying business objects, and grouping into layout controls. My goal
is to have both applications have a similar look and feel as far as form
functionality, navigating around the application, etc., but via the
controller each could also exploit advantages peculiar to the environment.

One other aspect of this has come out from watching and reading some of the
material. I know that part of WPF and XAML is the ability to declaratively
design a form, but I find it downright weird to be hand-typing form layouts
in 2006. Does VS2005 (with the right SDKs or whatever would be required)
have the ability to design a form in the designer and then output that as a
xaml definition? This would seem to get me a long way down the road I want
to go. I realize I may need to write an "interpreter" for the asp.net side
if it couldn't use the same definition.

I've spent a few days with Workflow Foundation, and see that there is kind
of two things talked about - the workflow classes on the one hand, and the
declarative ability to interact with the host "engine" on the other. So, WF
is not defined by declarative flow design, but is the technology that enables
it. I'm presuming now the same applies to WPF - it's not defined by xaml per
se, but is the technology that will enable xaml programming in Windows. Does
that sound right?

--
"Drew Marsh" wrote:

> Daniel Billingsley wrote:
>
> > In all the info from MS, I can't seem to find a solid answer to this
> > question. I want to develop an application such that I can
> > essentially define a UI once and have it available as both a windows
> > forms application and ASP.NET application. I found one blurb
> > somewhere that WPF applied to both windows forms and web forms, but
> > that was about it.
> >
> > So, is it the case that I could define a UI form using XAML and have
> > WPF use that in the context of both windows forms application and
> > ASP.NET?
>
> The answer is: depends on what features you're using.
>
> There's two forms of WPF for the web: loose XAML and XBAP applications[1].
> Loose XAML would pretty much be used to create pretty pictures and animations.
> There's no code behind and you're limited to a sandboxed set of components[2]
> you can work with. Then there's XBAP applications. These, like loose XAML,
> will run in a sandbox, but can also have compiled code-behind. The code-behind
> can do anything with .NET that is possible in the Interet Zone. Note that
> you can also request higher levels of trust for an XBAP application[3].
>
> All said, you should easily be able share resources between these types of
> application and the straight up windows application. Code, on the other hand,
> will need to be zone aware.
>
> HTH,
> Drew
>
> [1] http://windowssdk.msdn.microsoft.com...c6bb8900df.asp
> [2] http://windowssdk.msdn.microsoft.com...0b1d032483.asp
> [3] http://blogs.gotdotnet.com/karstenj/...29/498061.aspx
>
> ___________________________________
> Drew Marsh
> Chief Software Architect
> Mimeo.com, Inc. - http://www.mimeo.com
> Microsoft C# / WPF MVP
> Weblog - http://blog.hackedbrain.com/
>
>
>

Daniel Billingsley wrote:

> If I understand [1] correctly it's talking about essentially an easy
> way to deploy xaml-based applciations that still run in the WPF
> context on the client (and therefore require it on the client), which
> is something quite different than an HTML-based web application. Is
> that correct?

Oh, absolutely. No matter what approach you take, the WPF runtime components
are required on the client.

> One other aspect of this has come out from watching and reading some
> of the material. I know that part of WPF and XAML is the ability to
> declaratively design a form, but I find it downright weird to be
> hand-typing form layouts in 2006. Does VS2005 (with the right SDKs or
> whatever would be required) have the ability to design a form in the
> designer and then output that as a xaml definition? This would seem
> to get me a long way down the road I want to go. I realize I may need
> to write an "interpreter" for the asp.net side if it couldn't use the
> same definition.

Yes, this is coming with Visual Studio Orcas and the codename of the engine
is Cider. You can download a CTP here[1]. You should also check out Expression
Interactive Designer[2]. It's geared more towards the designer, but as an
editor for WPF content it's further ahead than Cider right now.

> I've spent a few days with Workflow Foundation, and see that there is
> kind of two things talked about - the workflow classes on the one
> hand, and the declarative ability to interact with the host "engine"
> on the other. So, WF is not defined by declarative flow design, but
> is the technology that enables it. I'm presuming now the same applies
> to WPF - it's not defined by xaml per se, but is the technology that
> will enable xaml programming in Windows. Does that sound right?

Yes, a WWF workflow can also be declared using XAML. XAML is not strictly
tied to WPF. I wouldn't be surprised if we see more products/APIs leveraging
XAML in the future.

Cheers,
Drew

[1] http://www.microsoft.com/downloads/d...DisplayLang=en
[2] http://www.microsoft.com/products/ex...ree_trial.aspx

That's a bit of a holy grail for WinFX, IMO. I've been pining for it since
ASP.Net 2 came out, as both have (different) skinning but share a lot of
objects in common. A couple of other folks have brought it up on wishlists,
but I've honestly never heard anyone from MS say one thing or the other on
it as a proposal. I'm actually surprised that no one has put into public
domain a XamlToAsp2.xslt/Asp2ToXaml.xslt whereby functionality holes are
gracefully handled by the transform & you get some kind of equivalency with
no modification; WPF is much, much richer than ASP/HTML, but I still think
it's quite within the realm to have a graceful fallback to HTML with
degraded rather than removed functionality (the logical trees of the two
have much more in common that the visual).
Maybe they're saving it for ASP.Net 3. By then, I'm hoping it gets WPF's
visual tree paradigm so the two programming disciplines get merged, but
going that route means a horrendous break in existing pages (unless MS comes
up with Asp2ToAsp3.xslt)

Well said Keith.

It sounds like maybe using xaml as the form definition could potentially
bear fruit down the road, but beyond that I'll have to pretty much blaze my
own trail or find 3rd party help.

"Keith Patrick" <richard_keith_patrick@nospam.hotmail.com> wrote in message
news:%23P8LAvyYGHA.508@TK2MSFTNGP02.phx.gbl...
> That's a bit of a holy grail for WinFX, IMO. I've been pining for it
> since ASP.Net 2 came out, as both have (different) skinning but share a
> lot of objects in common. A couple of other folks have brought it up on
> wishlists, but I've honestly never heard anyone from MS say one thing or
> the other on it as a proposal. I'm actually surprised that no one has put
> into public domain a XamlToAsp2.xslt/Asp2ToXaml.xslt whereby functionality
> holes are gracefully handled by the transform & you get some kind of
> equivalency with no modification; WPF is much, much richer than ASP/HTML,
> but I still think it's quite within the realm to have a graceful fallback
> to HTML with degraded rather than removed functionality (the logical trees
> of the two have much more in common that the visual).
> Maybe they're saving it for ASP.Net 3. By then, I'm hoping it gets WPF's
> visual tree paradigm so the two programming disciplines get merged, but
> going that route means a horrendous break in existing pages (unless MS
> comes up with Asp2ToAsp3.xslt)
>
>

From the application/content flavor standpoint you have these in order of
feature-richness:

Loose or uncompiled XAML --> WPF browser-hosted app (XBAP) --> WPF
standalone Window-based app

Loose XAML is the most trivial of these three and does not qualify as an
application. The other two do. With XBAPs and Window-based apps, you
essentially use the same programming model. The fork is just in a couple
build properties. Although, XBAPs operate in a partial trust sandbox within
the browser and hence have restrictions on doing certain security sensitive
tasks. Because of this, the transition from XBAP to Window-based app is
easier than the other way round. The other way round is possible, though, if
you write logic around the code that requires elevation.

This isn't quite Winforms->ASP.NET in terms of technology, but very similar
from the application and business scenarios.

--
Ashish Shetty [MSFT]
Program Manager, Windows Presentation Foundation (Avalon)
Blog: http://nerddawg.blogspot.com



"Daniel Billingsley" <DanielBillingsley@newsgroup.nospam> wrote in message
news:eWTvGxTaGHA.5004@TK2MSFTNGP02.phx.gbl...
> Well said Keith.
>
> It sounds like maybe using xaml as the form definition could potentially
> bear fruit down the road, but beyond that I'll have to pretty much blaze
> my own trail or find 3rd party help.
>
> "Keith Patrick" <richard_keith_patrick@nospam.hotmail.com> wrote in
> message news:%23P8LAvyYGHA.508@TK2MSFTNGP02.phx.gbl...
>> That's a bit of a holy grail for WinFX, IMO. I've been pining for it
>> since ASP.Net 2 came out, as both have (different) skinning but share a
>> lot of objects in common. A couple of other folks have brought it up on
>> wishlists, but I've honestly never heard anyone from MS say one thing or
>> the other on it as a proposal. I'm actually surprised that no one has
>> put into public domain a XamlToAsp2.xslt/Asp2ToXaml.xslt whereby
>> functionality holes are gracefully handled by the transform & you get
>> some kind of equivalency with no modification; WPF is much, much richer
>> than ASP/HTML, but I still think it's quite within the realm to have a
>> graceful fallback to HTML with degraded rather than removed functionality
>> (the logical trees of the two have much more in common that the visual).
>> Maybe they're saving it for ASP.Net 3. By then, I'm hoping it gets WPF's
>> visual tree paradigm so the two programming disciplines get merged, but
>> going that route means a horrendous break in existing pages (unless MS
>> comes up with Asp2ToAsp3.xslt)
>>
>>
>
>