I've been trying to sort this out for some time now..
I have a few .NET libraries that work as an SDK to an external application. I need to use that SDK both from a WPF Class Library and a Silverlight Class Library. I've been reading a lot of solutions including:
Portable Class Libraries - When I try to add the SDK libraries to the project, it complains that those libraries reference .NET 2.0 libraries and it is incompatible.
WCF RIA - I may be doing this wrong, but everywhere I turn, one step of the process is to create an Entity with the EF. Now, I don't want to access a DB, just those libraries.
But so far, no luck. Any ideas you would like to share?
As far as I know, it may not work if the old .NET 2.0 binaries have references to COM or system libraries. That could relate to your DB implementation. I have had this problem in a project in a previous job. We solved this by creating a WCF service as a in-between solution. That was WCF and not WCF RIA.
If the .NET 2.0 code is really old, you should check if it must be compiled as x86 and hosted as a 32-bits application on AppPool of the site that hosts the WCF service in the IIS.
But this is tricky business, and it all depends on the complexity of the old .NET 2.0 library file and its references.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am trying to get my head round the new Windows 8 Runtime that is used to create Metro style apps. I know you can use it with XAML and it is based on .NET so C# and VB.NET can be used to write the apps, but then it seems to have something to do with HTML, CSS, DOM, and JavaScript.
Can someone explain what it is in a few paragraphs, in terms that a .NET UI programmer can understand? (I am missing something “key” that is necessary to understand it.)
We all know that WPF, Silverlight, Windows Forms, etc. will keep working under Windows 8 (and Windows 10) on at least on Intel systems, so please don't tell me that...
At the lowest level, WinRT is an object model defined on ABI level. It uses COM as a base (so every WinRT object implements IUnknown and does refcounting), and builds from there. It does add quite a lot of new concepts in comparison to COM of old, most of which come directly from .NET - for example, WinRT object model has delegates, and events are done .NET-style (with delegates and add/remove subscriber methods, one per event) rather than the old COM model of event sources and sinks. Of other notable things, WinRT also has parametrized ("generic") interfaces.
One other big change is that all WinRT components have metadata available for them, just like .NET assemblies. In COM you kinda sorta had that with typelibs, but not every COM component had them. For WinRT, the metadata is contained in .winmd files - look inside "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\" in Developer Preview. If you poke around, you'll see that they are actually CLI assemblies with no code, just metadata tables. You can open them with ILDASM, in fact. Note, this doesn't mean that WinRT itself is managed - it simply reuses the file format.
Then there are a number of libraries implemented in terms of that object model - defining WinRT interfaces and classes. Again, look at "Windows Metadata" folder mentioned above to see what's there; or just fire up Object Browser in VS and select "Windows 8.0" in the framework selector, to see what's covered. There's a lot there, and it doesn't deal with UI alone - you also get namespaces such as Windows.Data.Json, or Windows.Graphics.Printing, or Windows.Networking.Sockets.
Then you get several libraries, which are specifically dealing with UI - mostly these would be various namespaces under Windows.UI or Windows.UI.Xaml. A lot of them are very similar to WPF/Silverlight namespaces - e.g. Windows.UI.Xaml.Controls is closely matching System.Windows.Controls; ditto for Windows.UI.Xaml.Documents etc.
Now, .NET has the ability to directly reference WinRT components as if they were .NET assemblies. This works differently from COM Interop - you don't need any intermediate artifacts such as interop assemblies, you just /r a .winmd file, and all types and their members in its metadata become visible to you as if they were .NET objects. Note that WinRT libraries themselves are fully native (and so native C++ programs that use WinRT do not require CLR at all) - the magic to expose all that stuff as managed is inside the CLR itself, and is fairly low level. If you ildasm a .NET program that references a .winmd, you'll see that it actually looks like an extern assembly reference - there's no sleight of hand trickery such as type embedding there.
It's not a blunt mapping, either - CLR tries to adapt WinRT types to their equivalents, where possible. So e.g. GUIDs, dates and URIs become System.Guid, System.DateTime and System.Uri, respectively; WinRT collection interfaces such as IIterable<T> and IVector<T> become IEnumerable<T> and IList<T>; and so on. This goes both ways - if you have a .NET object that implements IEnumerable<T>, and pass it back to WinRT, it'll see it as IIterable<T>.
Ultimately, what this means is that your .NET Metro apps get access to a subset of the existing standard .NET libraries, and also to (native) WinRT libraries, some of which - particularly Windows.UI - look very similar to Silverlight, API-wise. You still have XAML to define your UI, and you still deal with the same basic concepts as in Silverlight - data bindings, resources, styles, templates etc. In many cases, it is possible to port a Silverlight app simply by using the new namespaces, and tweaking a few places in code where the API was adjusted.
WinRT itself doesn't have anything to do with HTML and CSS, and it bears relation to JavaScript only in a sense that it is also exposed there, similar to how it is done for .NET. You don't need to deal with HTML/CSS/JS when you use WinRT UI libraries in your .NET Metro app (well, I guess, if you really want to, you can host a WebView control...). All your .NET and Silverlight skills remain very much relevant in this programming model.
From the Build keynote:
They're providing common APIs to both HTML/CSS/JavaScript apps and C#/XAML apps. C# and XAML will be used, but it won't be WPF or Silverlight exactly.
The key idea is that now there is two development tracks - the Desktop and Metro.
The desktop is where the old apps live.
The new class of applications, Metro applications, can be built in a number of ways, including by VB.NET, C# or C++. These three language options can use XAML for building the UI. The alternative is to use JavaScript/HTML5/CSS for the development of both the UI and application code.
Some important points:
Windows 8 feels sort of like an upscaled mobile phone OS.
In Metro, there are no overlapping top-level windows, just as there are none on a mobile phone. If you want an MDI style application, you need to stay on the desktop.
Metro style apps are automatically suspended when not visible. This was done to prolong battery life. This means it won't make sense for many existing desktop apps, which perform background processing even while the user is not interacting with them, to be ported to Metro.
The ARM version of Windows 8 will not support desktop applications. So if you want to write an app and you want it to work on any version of Windows then it has to be a Metro app.
There's modified version of the architecture that'll surely help you understand where exactly the things lies. One of the Telerik ninjas had chat with the CLR team and modified the picture:
Here you can see where the CLR stands. The .NET framework now has two profiles
1- .NET Metro profile (CLR that deal with Metro application)
2- .NET Client profile (CLR runtime for C# and VB.NET applications)
I hope this gives you a clearer picture. Read the full article in A bad picture is worth a thousand long discussions..
Lots of detail from Microsoft here.
The Windows Runtime is exposed using API metadata (.winmd files). This is the same format used by the .NET framework (Ecma-335). The underlying binary contract makes it easy for you to access the Windows Runtime APIs directly in the development language of your choice. The shape and structure of the Windows Runtime APIs can be understood by both static languages such as C# and dynamic languages such as JavaScript. IntelliSense is available in JavaScript, C#, Visual Basic, and C++.
In short, Windows Runtime is a new set of libraries exposing Windows functionality and available to JavaScript/C#/VB/C++. Each language has been made to understand and be able to call them directly rather than having to go through some thunking layer.
Silverlight and WPF are flavors of XAML that run on the CLR. Among other functionality, Windows Runtime exposes a version of XAML very similar to Silverlight, but does so in a native way, not via the CLR. It can be accessed from the CLR, but also from C++.
Having never written a production quality Silverlight app, I am looking to find a quality open source reference application for Silverlight 3.0 (Silverlight 4.0 is no good as I have VS2008) to help learn Silverlight.
Ideally I'd like to see:
a line of business application, in the client-server tradition.
SQL Server back end
no use of 3rd party libraries like PRISM or CSLA as I would like to see how the core Silverlight technologies work.
I realise there are plenty of open source projects on Codeplex, but struggled to find any classic line of business apps there.
This is a really good one:
http://timecard.codeplex.com/
The following does use Prism, but you can learn a lot from it. It even shows localization:
http://happynet.codeplex.com/
In all honesty, get yourself upgraded to VS 2010. If you are serious about becoming a professional in Silverlight development, version 4 has the most bang-for-your-buck.
Not all the newer technologies are supported for Silverlight 3 and all the latest cool tutorials and project examples tend to be in VS2010/SL4.
You also should not ignore patterns like MVVM and libraries like Prism & MEF as they are rapidly becoming commonplace for Silverlight projects. There is more danger of you getting into Win-forms-style bad habits if you use a Win-forms style approach to Silverlight at first.
Here is a simple explanation of MVVM for Silverlight:
http://openlightgroup.net/Blog/tabid/58/EntryId/89/Silverlight-View-Model-Style-An-Overly-Simplified-Explanation.aspx
These videos are a good introduction to creating/understanding Prism-based projects, specifically for Silverlight:
http://channel9.msdn.com/posts/mtaulty/Prism--Silverlight-Part-1-Taking-Sketched-Code-Towards-Unity/
It includes him building an Outlook-style application using prism (with full source provided).
The codeplex project, full source and documents etc, for Prism and soon MEF is here:
http://compositewpf.codeplex.com/wikipage?title=Getting%20Started&referringTitle=Home
Prism was created by Microsoft and will soon have a final release of version 4 (including MEF).
I'm interested in using F# for numerical work, but my platforms are not windows based. Mono still has a significant performance penalty for programs that generate a significant amount of short-lived objects (as would be typical for functional languages).
Silverlight is available on OSX. I had seen some reference indicating that assemblies compiled in the usual way could not be referenced, but not clear on the details. I'm not interested in UIs, but wondering whether could use the VM bundled with silverlight effectively for execution?
I would want to be able to reference a large library of numerical models I already have in java (cross-compiled via IKVM to .NET assemblies) and a new codebase written in F#. My hope would be that the silverlight VM on OSX has good performance and can reference external assemblies and native libraries.
Is this doable?
Technically speaking, Silverlight assemblies are similar as normal CLR assemblies, with the exception that they reference different version of runtime (and different version of system libraries such as mscorlib). Silverlight can run only Silverlight assemblies, so if you're compiling F# code you need to instruct the F# compiler to reference Silverlight (here are Visual Studio templates from Luke Hoban and here is a recent sample Silverlight app in F# by Brian McNamara).
Now, regarding the non-F# assemblies, I'm afraid this may be a problem. In principle you don't need to recompile them - there are tools to change the version (to turn CLR assembly into Silverlight assembly). See for example this article. In practice, Silverlight has many limitations (lots of methods missing, you are not allowed to do some Reflection tricks for security reasons etc.). So, I'm afraid that if you simply convert the assembly to Silverlight, it won't really work, but you may still try that... (but be careful - if a referenced method is missing, you won't find this out until Silverlight tries to call it at runtime).
Finally, there is also a problem with communicating with the application running in Silverlight as Silverlight apps have pretty limited capabilities. However, Silverlight 4 RC should allow you to read/write local files when running in the Out-of-browser mode (which may be good enough).
In summary I think that there are a lot of issues that may make it impossible to use Silverlight for this. I would maybe consider doing some more testing on Mono and sending feedback to them (if you find some case where the performance is clearly poor) - From my experience, they can be quite effective in responding to the feedback from users and I have the feeling that F# may be quite interesting thing for Mono team.
Is it possible to build a good medium to full sized application using just silverlight as a host?
A few things that would be needed:
- dynamic pages (one silverlight "screen" can switch between screens, like a normal app.
- similar to a java applet which launches from the browser
I see that Telerik sells RadControls for WPF...but this is only useful (to me) if Silverlight can be a rich client platform through the web.
Although still a somewhat immature platform, Silverlight 2.0 supports many of the features that I would expect from a platform needed to create full sized applications.
Data access through web services and local data/object query support with Linq
Many feature rich controls such as datagrid, treeview, etc
A very usable subset of the CLR (common language runtime)
Access to restricted local storage on the client machine
It is cross platform
There are already some great add-ons, like Telerik and the Silverlight Control Toolkit
For your specific scenario, Microsoft has published a tutorial on Multi-page Applications
Absolutely. I've been looking into this and believe that it's as easy to do in Silverlight as it is in any other language. Remember that Silverlight 2 uses C# 3.0 and from that you can build anything that's not included in the Silverlight version of the CLR. Also, the fact that Microsoft gives you access to the .NET source code means that you can compile the missing parts of the .NET libraries with your application. (No idea about the licensing issues with that though.)
I've seen a presentation of a full featured CRM application two days ago. Although it's still alpha: It looks and feels like any office application. I don't know details but for me it's a proof of concept.