Silverlight beta 4 (IDataErrorInfo)

[Colin Eberhardt]

I see Silverlight beta 4 is out ... already:

http://silverlight.net/getstarted/silverlight-4-beta/

Lots of great new features, including IDataErrorInfo - something which
I think Josh shouted about here a few month back!

Regards,
Colin E.

[Karl Shifflett]

I posted on Silverlight 3 & 4 Library Sharing with .NET 4.0 Library or WPF.

http://karlshifflett.wordpress.com/2009/11/19/silverlight-3-4-library-sharin
g-with-net-4-0-library-or-wpf/

No more linked files!!!

Enjoy this great feature.

kdawg

[Karl Shifflett]

The data stack in SL 4 has many improvements and the Binding API is on par
with WPF.

ValidatesOnDataErrors (enables IDataErrorInfo)
TargetNullValue (enables binding to Nullable types correctly)
StringFormat (say good-bye to most of those converters)

[Karl Shifflett]

I posted on Silverlight 3 & 4 Library Sharing with .NET 4.0 Library or WPF.

http://wp.me/p53lI-iM

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]

[Peter O'Hanlon]

Woo hoo. Excellent news on the Binding API - I might start to seriously consider SL now.

--
Peter O'Hanlon

[Bill Kempf]

What about IServiceContainer?

--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

War is peace. Freedom is slavery. Bugs are features.

[Colin Eberhardt]

WPF's younger brother (sister? [1]) finally grew up

Regards,
Colin E.

[1] OK ... we'll go for sibling to keep it PC.

On Nov 19, 1:36 pm, "Peter O'Hanlon" <pete.ohan...@gmail.com> wrote:
> Woo hoo. Excellent news on the Binding API - I might start to seriously
> consider SL now.
>

[Daniel Vaughan]

Nice one Karl, answers all the questions.
I had a little dance about this last night. It's huge.

On Nov 19, 2:30 pm, "Karl Shifflett" <molena...@comcast.net> wrote:
> I posted on Silverlight 3 & 4 Library Sharing with .NET 4.0 Library or WPF.
>
> http://wp.me/p53lI-iM
>
> -----Original Message-----
> From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
>
> On Behalf Of Karl Shifflett
> Sent: Thursday, November 19, 2009 5:21 AM
> To: wpf-di...@googlegroups.com
> Subject: [WPF Disciples] Silverlight 3 & 4 Library Sharing with .NET 4.0
> Library or WPF
>
> I posted on Silverlight 3 & 4 Library Sharing with .NET 4.0 Library or WPF.
>

> http://karlshifflett.wordpress.com/2009/11/19/silverlight-3-4-library...

[Shawn Wildermuth]

I am curious, is .NET 4 fixing up the MSCorlib, System (and other .dlls) for
Silverlight project automagically? What about SL toolkit versus WPF
controls...any idea what the limits of this feature really are?

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Karl Shifflett
Sent: Thursday, November 19, 2009 8:21 AM
To: wpf-di...@googlegroups.com

[mole...@comcast.net]

Shawn,

 

Not exactly sure how far this goes.

 

I don't think there is magic here, just compat between namespaces in both plaform's .dlls.

 

I can look into the deep details when I get back from vacation.

 

I've been using/testing this and have not had any issues with my framework and entity sharing.

 

Karl

[Michael Sync]

Hi Karl,

 

I had same idea of using Silverlight assembly in .NET project when I was working for Prism-based project last year. But when the project was growning bigger and bigger, I faced a lot of problems.sometimes, we can't compile the project for some reasons. I think it might be because of binary compatibility issue. If I say my opinion, I don't recommend this way. Using Project Linker might be the best way of sharing the code between WPF and SIlverlight.

 

As there are a lot of WPF/Silverlight experts in our group, let's see others' feedbacks as well.

 

Thanks.

 

Regards,

Michael Sync

--
Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Corrado Cavalli]

Does it means that (ideally) a WPF application can consume WCF RIA Service
Library? :-)

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Karl Shifflett
Sent: giovedì 19 novembre 2009 14:31
To: wpf-di...@googlegroups.com

Subject: [WPF Disciples] Re: Silverlight 3 & 4 Library Sharing with .NET 4.0
Library or WPF (fixed link)

I posted on Silverlight 3 & 4 Library Sharing with .NET 4.0 Library or WPF.

http://wp.me/p53lI-iM

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Karl Shifflett
Sent: Thursday, November 19, 2009 5:21 AM
To: wpf-di...@googlegroups.com

[Karl Shifflett]

Michael,

 

You commented, “I faced a lot of problems. Sometimes, we can't compile the project for some reasons.”

 

That was last year, this capability is new.

 

If you start with a Silverlight Class library that does not reference Silverlight specific code, this works.

 

If you reference Silverlight Prism and expect cross compile, not sure you’ll get it. 

 

Maybe Glenn Block can comment on this.

 

What I’ve seen as the problem is, developers mix compatible code with non-compatible code.  This was actually very easy to do with File Linking and is a supported scenario. 

 

What I have found is that keeping the apples in one basket and the oranges in another basket always works.  Mixing the two, can under certain circumstances cause issues.

 

All that said, the “Utility of the Feature” is where the debate could be.

 

I love this feature for the capability to share business entities and framework code that I use in WPF too.

 

I’m sure there are other scenarios where developers will take this, but will hit a wall.  When that happens, report it on MS Connect.

 

Cheers,

 

Karl

[Karl Shifflett]

Corrado,

Not sure this feature enables that scenario but that scenario might just be
enabled having nothing to do with this.

Best place to get the answer is here:

http://forums.silverlight.net/forums/53.aspx

Cheers,

Karl

[Daniel Vaughan]

As I understand it, the Silverlight framework is not a subset of the
Desktop framework. Therefore, the consumed Silverlight assembly must
limit its calls to those that are the intersection of the Desktop
framework and the Silverlight framework. Development of any
Silverlight assembly will have to be done with this in mind. I see
this feature as being of real value mainly for, as Karl said, sharing
business entities, and also common platform agnostic business logic. I
know though that I will be using Silverlight assembly referencing very
soon. I am happy that I won't have to link in every single file, and
that Resharper will no longer present types to me in duplicate. Cool.

> http://karlshifflett.wordpress.com/2009/11/19/silverlight-3-4-library...

[Glenn Block]

It depends on which libraries you ref. The core cal I believe is UI
agnostic and should work. The UI library which contains Region
attached props / adapters is not.

Glenn

> <http://karlshifflett.wordpress.com/2009/11/19/silverlight-3-4-library-shari
> ng-with-net-4-0-library-or-wpf/>

> g-with-net-4-0-library-or-wpf/
>
> No more linked files!!!
>
> Enjoy this great feature.
>
> kdawg
>
>
>
>
>
>
>
> --
> Don't go the way life takes you.
> Take life the way you go
>
> http://michaelsync.net
>
>

--
Sent from my mobile device

[Karl Shifflett]

Karl's first official post in C#. Yes, I'm a member of the dark side now
and yes the C# editor is better than VB.NET. I've also gotten over my " { }
; " allergy.

I've done Part I of a 2 part series on writing design-times for custom
controls for Visual Studio 2010.

http://karlshifflett.wordpress.com/2009/11/20/extensibility-series-wpf-silve
rlight-design-time-code-sharing-part-i/

The design-time code is actually pretty easy to write.

The above post takes you through getting the metadata loaded. I've included
a tutorial breadcrumb that walks you through the metadata loading pieces.

This post also makes use of a common design-time assembly that has the code
for both the WPF & Silverlight versions of the custom control I provided.

On my way to Hawaii to board a ship to write code for a week.

Cheers,

kdawg

[Karl Shifflett]

I'm 95% done with my GridSplitter control I promised you.

During testing of my control, I discovered a bug in the WPF GridSplitter
during the process. That took me time to prove it was not my control, get
the bug submitted into the bug system and figure out a workaround.

I'll write the blog post after Thanksgiving.

Cheers,

kdawg

[Karl Shifflett]

I keep forgetting the links get split when they are long.

http://wp.me/p53lI-j9

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Karl Shifflett
Sent: Friday, November 20, 2009 9:50 PM
To: wpf-di...@googlegroups.com

[Peter O'Hanlon]

Good job mate, and enjoy your "holiday", but I see that holiday for you means change your location for coding.

--
Peter O'Hanlon

[Glenn Block]

Only assemblies that do not reference the UI stack are portable.
System.Core, MSCoreLib etc.

Glenn

--

[Bill Kempf]

Which is an 90% solution, and quite nice. However, I'd really like to
have some attention paid to writing portable UI code. The conditional
compilation stuff we have to do today, while it works, isn't ideal.

--

[Glenn Block]

Also commands, INCC, etc are now type forwarded in 4.0 so that they do
not reside in the UI stack thus they should be portable.

[Jaime Rodriguez]

Hi,

Assembly Portability is not quite all non-UI assemblies. Going from memory, I recall mscorlib, System.dll, System.Core.dll and System.ComponentModel.Composition (maybe there is one more than that). You of course have to use 'compatible' APIs within the assemblies.

Richard Lander (the PM owning) will be posting on this soon.. let's wait until then and then share our feedback. He is eager to hear it.

Thanks!

[Glenn Block]

I agree....baby steps.

We are working on a new portable subset in CLR that will work across
all runtimes. ( Eventually it will likely have portable UI
abstractions as well.

[Michael Sync]

Hey Karl,

Great.. Thanks a lot.I will be waiting your post.. :) 

Regards,
Michael Sync

[Sacha Barber]

Great post Karl

On Sat, Nov 21, 2009 at 5:50 AM, Karl Shifflett <mole...@comcast.net> wrote:

--
Sacha Barber
sacha....@gmail.com

[Sacha Barber]

Me too, I had to actually do one of these the other day, but I cheated as I knew Karl would be on the case and just used an expander for a quick and dirty hack. Looking forward to it Karl, let us know when you have the code available mate.

--
Sacha Barber
sacha....@gmail.com

[Bill Kempf]

I wrote the original response in a hurry, and mybe didn't explain the
pain points well. After reflection on it, I think there's really only
a few things that need to be done.

1. Provide some guidance material. Explain how you can use partial
classes/methods to keep code clean of too many pragmas that cause
maintainance issues.

2. Provide official #defines that are automatically defined by the
various platforms (I honestly don't remember if this was done, I just
have a vague recollection of having to define my own in Onyx).

3. Make platform choice something that you can tie to a project's
configuration, rather than to the project! This is the big one. Today,
you have to have separate project's and use file linking in one of
them. This is a tedious and error prone task. It would be much better
if I could have a single project with "WPF Debug"/"WPF
Release"/"Silverlight Debug"/"Silverlight Release" configurations.
This could even benefit developers that want to have projects that
target different versions of the runtime.

[Michael Sync]

Hello Karl,

How are you? Sir  :)   you know what I meant.  I'm still waiting you.  you know? :) 

Regards,

Michael Sync

On Sat, Nov 21, 2009 at 1:53 PM, Karl Shifflett <mole...@comcast.net> wrote: