Laden...

Silverlight 3 & Expression Blend 3 kommen im Juli

Erstellt von BFreakout vor 14 Jahren Letzter Beitrag vor 14 Jahren 8.836 Views
BFreakout Themenstarter:in
390 Beiträge seit 2006
vor 14 Jahren
Silverlight 3 & Expression Blend 3 kommen im Juli

Microsoft gab nun Offiziell bekannt das Silverlight 3 & Expression Blend 3 am 10. Juli 2009 in der Finalen Version veröffentlicht wird.

Die Testphase der beiden Betas endet somit und wird in San Francisco mit einem speziellen Launch-Event mit dem Titel "See the light" veröffentlicht.

Quellen und weitere Informationen:
http://www.theregister.co.uk/2009/05/29/silverlight_3_beta_july/
http://winfuture.de/news,47511.html
http://www.infoweek.ch/internet/web-designprogrammierung/articles/189741/

Kostenfreie Veranstaltung zu Silverlight 3 & Expression Blend 3:
http://www.dotnet-blog.net/post/2009/05/18/Silverlight-Roadshow-Mit-Silverlight-das-Web-entdecken.aspx

Viele Grüße,

BFreakout

DotNet-Blog.NET - Every day is an experience!
http://www.dotnet-blog.net

1.433 Beiträge seit 2006
vor 14 Jahren

Gibts schon eine Liste von Änderungen zu SilverLight 2.0? So als Zusammenfassung.

Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt

4.207 Beiträge seit 2003
vor 14 Jahren

http://timheuer.com/blog/archive/2009/03/18/silverlight-3-whats-new-a-guide.aspx

Edit: Die Seite ist relativ häufig down, im Falle des Falles bei Google nach "tim heuer silverlight 3 whats new a guide" suchen, und die Version im Cache angucken ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

1.433 Beiträge seit 2006
vor 14 Jahren


>

Edit: Die Seite ist relativ häufig down, im Falle des Falles bei Google nach "tim heuer silverlight 3 whats new a guide" suchen, und die Version im Cache angucken ...

Danke Golo 👍

Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt

K
111 Beiträge seit 2006
vor 14 Jahren


>

Edit: Die Seite ist relativ häufig down, im Falle des Falles bei Google nach "tim heuer silverlight 3 whats new a guide" suchen, und die Version im Cache angucken ...

Echt super die Seite, danke auch nochmal.

925 Beiträge seit 2004
vor 14 Jahren


>

Edit: Die Seite ist relativ häufig down, im Falle des Falles bei Google nach "tim heuer silverlight 3 whats new a guide" suchen, und die Version im Cache angucken ...

Ich schließe mich den Danksagungen mal an. (vielleicht wäre ein Bedank-o-mat im Forum gar nicht schlecht 😉 )

467 Beiträge seit 2007
vor 14 Jahren

Habe das nicht sehr gründlich gelesen, da ich von Silverlight wenig verstehe, aber mir scheint, Silverlight bewegt sich hiermit noch weiter von WPF weg? Sehe ich das richtig?

1.433 Beiträge seit 2006
vor 14 Jahren

Habe das nicht sehr gründlich gelesen, da ich von Silverlight wenig verstehe, aber mir scheint, Silverlight bewegt sich hiermit noch weiter von WPF weg? Sehe ich das richtig?

Meiner Meinung nach eher falsch. Denn mit der Version 3 ist es möglich ein Binding wie in WPF durchzuführen und dies ist eine Annäherung an WPF.

Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt

4.207 Beiträge seit 2003
vor 14 Jahren

Ich würde auch eher sagen, dass sich SL auf WPF zubewegt.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

1.433 Beiträge seit 2006
vor 14 Jahren

Ich würde auch eher sagen, dass sich SL auf WPF zubewegt.

In zwei drei Jahren wird WPF auch Browser-Unabhängig sein und es wird eventuell ein Template in VisualStudio geben dass WPF in a Sandbox oder so ähnlich heisst, geben.

Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt

BFreakout Themenstarter:in
390 Beiträge seit 2006
vor 14 Jahren
...

Gibt es bereits schon und heißt hier XBAP. Wird sogar langsam Browser-Unabhängig, für Firefox folgt noch ein Plug-In..

Nur wird dafür das .NET-Framework 3 gebraucht.. und ist somit nur unter Windows verfügbar.

Die Sandbox von XBAP Anwendungen ist allerdings um einiges härter.. da meines wissens die Datenkommunikation nicht so einfach seien soll.

Klar wird versucht die Grundlegenden Dinge wie Data-Binding zu vereinheitlichen. Finde ich auch wichtig. Kritisch sehe ich es aber bei WPF 4.0 Features die eventuell ja auch mit Silverlight folgenen könnten. Die aber dann nur noch auf Windows Betriebssystemen lauffähig wäre.. Wie zum Beispiel Multi-Touch...

DotNet-Blog.NET - Every day is an experience!
http://www.dotnet-blog.net

4.207 Beiträge seit 2003
vor 14 Jahren

Was mich in dem Zusammenhang mal interessieren würde: Nutzt irgendwer XBAP?

IMHO ist XBAP durch Silverlight obsolet geworden, und zumindest ich kenne auch niemanden, für den XBAP eine Option wäre.

Wie seht Ihr das?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

BFreakout Themenstarter:in
390 Beiträge seit 2006
vor 14 Jahren
...

Bei Kunden für die es eine Option gewesen wäre, war dann die Beschränkung auf Windows unsympathisch... Für eine Web-Anwendung sollte es dann schon flexibler sein. Vorallem macht mir deren Sandbox um weitem mehr Angst als die von Silverlight...

Interessant ist allerdings das Microsoft nicht aufgehört hat XBAP weiterzuentwickeln... spannend...

Würde mich auch Interessieren wer damit Projekte am laufen hat...

DotNet-Blog.NET - Every day is an experience!
http://www.dotnet-blog.net

4.207 Beiträge seit 2003
vor 14 Jahren

Das Problem bei XBAP ist IMHO: Man muss .NET deployen. Und wenn man das macht, kann man auch direkt eine Client-App deployen, was ja zB über ClickOnce kein wirklicher Aufwand ist.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

C
157 Beiträge seit 2008
vor 14 Jahren

Hi Leute,

WFP hat meiner Meinung nach definitiv eine Daseinsberechtigung. Man sollte nämich auf keinen Fall die Mächtigkeit die WPF-Browser-Applikationen gegenüber Siverlight bieten unterschätzen. WPF macht meiner Meinung nach nämlich immer dann Sinn, wenn die Plattformunabhängigkeit nicht unbedingt einen Rolle spielt.

Ein Beispiel hierfür wäre z.B. einen Intranet-Lösung für einen Firma, wenn deren Netzwerk ausschließlich Windows-Rechner beinhatet. Warum sich in diesem Fall mit der Eingeschränktheit von Siverlight abgeben, wenn einem mit WPF die ganze Welt offen steht.

Einen WPF-Browser-Applikation auf einem IIS im Firmen-Netzwerk, kann so bequem über den Browser aller Cliens genutzt werden. Diese ist zentral wartbar und einer Siverlight-Lösung oder iner Lösung, die ein fest installierte Appkikation auf jedem Client vorsieht generell immer vorzuziehen.

Zum Thema Plattformunabhängikeit will ich außedem noch auf MONO hinweise. Dieses unterstützt zwar aktuell nur .NET 2.0, aber es wird ja auch stetig weiterentwickelt. Eine plattformunabhängige WPF-Browse-Applikation wird also in nhr Zukunft auch möglich sein.

Also ich für meinen Teil arbeie jedenfalls aktuell an einem WPF-Browser-Projekt, welches ich so wie es geplant und konzipiert ist sicher nicht mit Siverlight umsetzen könnte.

Gruß
Core

4.207 Beiträge seit 2003
vor 14 Jahren

Und warum nimmst Du dann nicht "echtes" WPF mit ClickOnce?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

C
157 Beiträge seit 2008
vor 14 Jahren

Hi Golo,

ich bin immer offen für neues und mit ClickOnce habe ich mich noch nicht beschäftigt.

Warum sind denn für dich nur WPF-ClickOnce-Apps "echt"? Heißt das, dass WPF-Browser-Apps "unechte" WPF-Apps sind?

Wo sollen denn deinen Meinung nach die gravierenden Vorteile von ClickOnce-Apps gegenüber WPF-Browser-Apps liegen?

Core

4.207 Beiträge seit 2003
vor 14 Jahren

Andersrum gefragt:

Es gibt WPF und es gibt Silverlight. Das eine ist klar auf den Desktop ausgelegt, das zweite aufs Web. So weit so gut.

Die von Dir genannten Intranetapps sind so ein Zwischending. Hierfür wurde XBAP eingeführt.

Allerdings stellt sich mir die Frage nach dem Sinn:

Ich muss zwar die App nicht deployen (wie bei Silverlight), ich muss aber das .NET Framework deployen (wie bei WPF).

Insofern geht mir der Vorteil des einfachen Deployments wie bei SL verloren, aber auch der Vorteil von WPF, ohne Sandbox arbeiten zu können.

Da frage ich mich halt, warum ich XBAP dann überhaupt nehmen sollte, und nicht einfach eine normale WPF-App schreibe, bei der ich .NET zwar auch verteilen muss, ich mich aber ansonsten nicht mit einer Sandbox herumschlagen muss.

Und für das Deployment gibt es ja leichte Wege, wie beispielsweise ClickOnce.

Wie gesagt - ich verstehe einfach den Sinn von XBAP nicht. Welchen Vorteil habe ich durch den Einsatz von XBAP, der mir bei SL oder WPF verwehrt bleibt?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

C
157 Beiträge seit 2008
vor 14 Jahren

Hi Golo,

der Vorteil gegenüber Silverlight ist sicherlich der Funktionsumfang. Die Sandbox kann nämlich, im Gegensatz zu Silverlight unter der Nutzung von Zertifikaten umgangen werden. Dies Stellt meiner Meinung nach auch kein Sicherheitsproblem dar, denn wer sich ein Zertifikat für eine App in der Browser läd, geht i.d.R. davon aus, dass die App sicher ist.

Was die Sache mit dem ClickOnce-Apps angeht, sehe ich nicht wirklich den Unterschied. Tatsache ist doch, dass ich bei einer Web-App. egal ob im Inter- oder Intranet, nichts lokal installieren will. Alles sollte temp. gespeichert werden. Wenn beim Starten der XBAP prüft der Browser immer auch, ob die lokal im Temp.-Ordner gespeicherte Version die Neuste ist. Sollte auf dem Web-Server eine neuere Version sein, wird die auf dem Client temp. lokal gespeicherte automatisch durch diese ersetzt. Es ist also eine in sich logische, in sich konsistente Sache und macht für mich Absolut Sinn.

Welche Gründe sprechen denn nun deiner Meinung nach dagegen, bzw. preferieren ClickOnce. Kurz gesagt, was können ClickOnce-Apps, was XBAPs nicht können?

Gruß
Core

4.207 Beiträge seit 2003
vor 14 Jahren

Der Vorteil gegenüber SL liegt auf der Hand, so weit gebe ich Dir recht.

Der Vorteil von ClickOnce gegenüber XBAP ist IMHO, dass ClickOnce eine erprobte und vor allem technologieübergreifende Setupmethode darstellt: Es ist völlig wurscht, ob Du eine Konsolen-, eine Windows Forms-, eine WPF- oder eine sonstwas-Anwendung deployen willst.

XBAP hingegen ist ein einem Quasistandard nachgemachtes Deployment speziell für WPF, wobei WPF hier wiederum Abstriche machen muss. Stichwort Sandbox für XBAP.

Insofern sehe ich WPF + ClickOnce als leistungsfähiger an als XBAP.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

C
157 Beiträge seit 2008
vor 14 Jahren

Hi Golo,

ClickOnce-Apps werden aber nach meinem Verständnis immer auf dem Client lokal installiert. Diese werden dann zwar, ähnlich wie bei Java-Web-Start automatisch auf dem aktuellen stand gehalten, müssen aber in jedem Fall erst mal installiert werden.

Was aber, wenn das nicht gewünscht ist? Es gibt sicherlich auch Situationen, wo der Kunde keine Installation auf den Clients wünscht. XBAP-Apps installieren nichts, sondern speichrn ihre Date nur temporär.

So denke ich, dass XBAP eine sehr vorteilhafte Technologie sein kann, weil sie nach meinem Verständnis ein Hybrid aus Silverlight/ClickOnce ist. Klar kann man nun sagen, das hier versucht wurde, die Eier-Legende-Woll-Milch-Sau zu imitieren und die ganze Sache als nichts Halbes und nichts Ganzes abtun.

Aber einen Frage sollten wir uns dann doch schon stellen: Wenn XBAP eigentlich nicht notwendig ist, warum wird es dann so konsequent von Microsoft gefördert? Ich denke aus Sicht von Microsoft ist XBAP zumindests zur Zeit genau dafür gedacht, was ich bereits angesprochen habe: Windows-Intranet-Lösungen, bei denen RIAs zum Einsatz kommen und auf den Clients der Browser als zugangsschnittstelle zu den Apps genutzt werden soll.

Welche Technologie sich in Zukunft durchsetzen wird, kann doch heute sowieso keiner von uns sagen (Bsp. LINQ vs. EntityFramework vs. klassisches ADO.NET).

Mal angenommen MONO würde WPF eines Tages beinhalten und als Standard in die gängigsten LINUX-Distris aufgenommen werden (ähnlich, wie Java), Apple würde aus welchen Gründen auch immer ebenfalls einlenken und in 2 bis 3 Jahren haben die meisten Windows-Nutzer ohnehin Vista oder 7 statt XP, welche das Framework von hause aus beinhalten. Was spräche in diesem sicherlich sehr fiktiven Falle noch gegen XBAPs?

core

1.433 Beiträge seit 2006
vor 14 Jahren

Hier noch die Guidance on Differences Between WPF and Silverlight

Dank an Tim Heuer für den Tweet 👍

Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt

4.207 Beiträge seit 2003
vor 14 Jahren

Hi core,

ich muss zugeben, dass mit der Aspekt der Nicht-Installation bislang nicht bewusst war. Das ist natürlich ein Argument.

Insofern muss ich meine Meinung ein bisschen revidieren - in dem von Dir beschriebenen Szenario wäre das ganze durchaus sinnvoll.

Allerdings: Sobald Silverlight (in einem ähnlich hypothetischen Szenario) näher an WPF dran ist bezüglich seiner Fähigkeiten, hätte man den gleichen Effekt wie mit XBAP mit Silverlight - nur ohne die Notwendigkeit, das Framework deployen zu müssen.

Insgesamt ist es aber wohl so, wie Du sagst: Man muss abwarten ...

Viele Grüße,

Golo

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

C
157 Beiträge seit 2008
vor 14 Jahren

Hi Golo,

in der Regel hat jeder immer ein bischen Recht. Kommt halt immer drauf an, von welcher Seite man das Problem beleuchtet. Allerdings muss ich anmerken, sollten eines Tages die Fähigkeiten von Silverlight denen von XBAPs das Wasser reichen können, dann müsste das Siverlight-Plugin um einiges erweitert werden. Genauer gesagt, es währe das .NET-Framework selbst.

In diesem Falle wären XBAP und Silverlight identisch. Die VM wird dann eben nicht mehr in das Betriebssystem selbst, sondern in den Browser als erweiterung eingebunden. Einen aus meiner Sicht sehr sinnvolle Entwicklung die, wie ich mir vorstellen kann, Microsoft sicherlich in dieser oder ähnlicher Form einschlagen wird.

core