What is the simplest way of converting my .NET C# windows forms app to a silverlight app?
Thanks!
You will need to re-write all GUI completely.
If you used any pattern separating business logic and data model from its presentation (MVC, MVP) it will be easier to port user interaction. If you used any database access layers or framework, they can most certainly be reused in Silverlight project. However, if your application logic is defined in form event handlers and data access is performed from within them, chances are high that you'll have to write a new application.
Also note that you can't use third-party libraries compiled for standard .NET Framework in Silverlight. You'll either need to recompile them, provided that you have the sources, or look for a specific Silverlight version of the binaries.
Standard .NET Framework libraries can easily be accessed, however there are some exceptions to the rule. For example, obviously, there is not System.Windows.Forms in Silverlight subset of .NET Framework.
To give you a better answer, I need more details: what kind of application are you considering to port, what libraries does it use, whether business logic is separated from presentation logic, etc.
Regarding the UI there is a Windows Forms to XAML Converter that may help a bit.
Related
I am working on c# desktop windows form application using some 3rd/.net libraries and all forms are not WPF and no MVC.
I searched about this and I have some questions.
I'm expecting to change the whole gui code to wpf/XAML/ html forms.
I have two options now using asp or silverlight.
If I converted the project to asp/silverlight can I use the existing 3rd/.net libraries and I think I won't be able to get source code to recompile it?
knowing that the application contains tons lines of code and 6 projects in one solution.
what do you recommend for less effort?
and I can't use gizmox because its commercial license
If you are moving from a WinForms to a Web Server based architecture, I would definitely recommend the MVC route. Silverlight as a technology is a dead end and in addition would not allow you to reuse .net code without recompilation. Using MVC allows you to re-use your existing code, for good or for ill, in the server tier without recompilation. Even if you did use the Silverlight technology you could wrapper your existing libraries in a WCF service tier on the server and have Silverlight call it as web service.
However; the move to a web based architecture will require you to re-write a lot of your code (almost all the UX code will need to be scrapped) and this raises the question of what you are trying to achieve by moving to a web based architecture; so you need to consider both the costs and effort as being substantial - there are no quick ways to move from WinForms to Web, but depending on your business requirements you might consider using ClickOnce or XBAP to distribute your existing Windows application via a browser.
Does anyone have experience with Xamarin trying to use allready existing .NET code? Especially Form.Elements - or do they have to be redesigned for java(Android)?
My second question is, whether it is possible to build an Xamarin-Library to use system.Forms elements?
No, you can't use Windows Forms code in Xamarin.
The idea of Xamarin is that it uses the UI framework which is native to the OS you're writing for - so that isn't portable - but you can share the business logic which will be common to all of your implementations.
So long as you have a clear delineation between UI and business logic, you can create a portable class library containing the business logic and share that very easily between any "normal" .NET environment and Xamarin.iOS / Xamarin.Android. (There may be other platform-specific parts too, such as local storage - again, it's a matter of isolating that and abstracting it where appropriate, so that your business logic may be able to say "Get me storage record X" and it will use whatever storage provider you've plugged in.)
I started work on porting an application I've written for deployment in the Windows 8 app store. This requires that the application be written against the subset of the .NET framework. My application follows an architecture where the core functionality is in it's own dll, and things like file system access are done through IoC. Basically, this means that the only dependency for the core dll is System. Because of this, I thought that porting would be a breeze - setup my IoC values and wire up a GUI then I'll be good to go. Only, I can't even reference my core dll from the windows store app (a.k.a. metro app).
Have I missed something? Do actually have to rewrite my core dll just for inclusion in the windows 8 app store? We're told that if you use a good architecture, then porting will be a breeze, and that's what I've done. Has that just been a big lie?
Windows store apps(formerly called metro style app) are limited to using the .NET Core Profile. I put some details about the Core Profile in my answer to this question. See Converting your existing .NET Framework code in this article more details. It's not your architecture, it's the subset of the .NET Framework that is available to a Windows store app. You may have to supplement some of the types you use in .NET with WinRT types instead.
I don't have an extensive knowledge and will try to stict to facts as I understand them. The Metro framework adds functionality, and limits functionality. There are heavy security restrictions and vast segments of the full .Net framework that are not available (for instance, you cannot use System.Data, some of the System.IO and file access methods have drastically changed). A Metro app is isolated, you're not going to be able to recurse all the files on the hard drive like you could in a standard application (my opinion that is, on top of security by isolation it's an encouragement to push you into the cloud for storage needs).
Unless things have changed, PInvoke is limited to "approved" Win32 API methods.
See this link for some alternatives to common Win32 API needs: http://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
See this link for approved Win32/COM API's: http://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
It's hard to say whether a "good" architecture will be a breeze to port without knowing what's in the code in that architecture. In my utility framework I've had things that ported very easily (or at least were straightforward) and things that were a complete wash that required a lot of rewriting (The loss of System.Data for instance is a sore spot for me). There are things that can be designed well but when you take out the underlaying code in the framework or API it was written with it will require rewriting.
I had the same problem: a project for Metro app don't load dll create with framework .4. I changed the framework from 4 to 3.5 for the dll and now the Metro project see them.
I'm pretty excitet about all the new stuff coming up in Windows 8, but at the same time a bit worried about how and if I can continue use the code and custom components I have already built up using .NET and C# during my time as a Windows dev. I've got some general mixed questions about this. Hope you don't mind I'm putting them together in one post:
Will Windows 8 Store be for both metro-style apps and regular WPF-desktop apps? Including pushing updates and making apps available for company employees?
Will the new App Contract-thingy also be available for WPF-apps? And is AppContract based on WCF-services with perhaps UDP-discovery on the network? Can I make my own contracts between my own apps using the App Contract framework?
I'm not particularly worried about if WPF will be ditched or not. I can live without it. The thing that worries me is if I still can write presentation and business-layer code in C# and use it as a backend for my apps, no matter what UI-framework I'll be using, HTML, Silverlight, WPF or what have you. If I'm still able to write logic in C# and present it using X UI-framework, I'm a happy developer. I've heard I can access the .NET-framework from JavaScript. But what about custom assemblies?
It has been announced that non-Metro apps can appear in the store but the store will just link to the publisher's website - not actually manage the sale/install/DRM/etc stuff.
What's been announced so far is that the contracts are only for Metro apps but I'd be shocked if this doesn't change. It would be crazy for Microsoft not to allow desktop apps to, for example, add commands to the Settings charm, support PlayTo or printing through the Devices charm, or act as Share sources. We'll have to wait and see where they draw the line on what desktop apps can/can't do.
Sharing code between Metro and non-Metro apps is going to be very difficult. A lot of the core concepts and conventions are the same but even basic stuff like file I/O rely on a totally new API. There aren't a ton of interesting things you can do with in code that will work on both sides of the fence. Best bet would be to define interfaces for your business layer stuff and then use dependecy injection to dynamically select desktop vs. winrt implementations at runtime
Store: there is no final information but as far as I understood it, it's for metro style applications only
The app contracts are a metro thing. I know a code snippet that documents usage from desktop apps (eg http://www.heise.de/developer/artikel/WinRT-in-klassischen-NET-Anwendungen-nutzen-1366039.html (sorry, German)), but I do not know if it will have support from Microsoft
WinRT compiles libraries to WinRT components. You might be able to reuse code and compile them to a component as long as you're not using a namespace that isn't available for WinRT
This question is heavy on guessing as there is no official beta available. And even then we can't be absolutely sure...
Many popular applications such as Wordpress, WHMCS and the majority of PHP forums allow plugins to hook into core application events (such as registration, logging in, create post etc.) by simply specifying a function with a particular name.
I understand that these applications are not pre compiled, but is it possible to do something of the sort with C#? I've looked into event handlers, but it seems that you can only accomplish this if the plugin has the ability to instantiate the class that we want to hook into (or at least thats what searching has lead me to believe)
Ideally, these hooks would be into business layer class events/methods and can be hooked into by multiple objects, so it would function in either WinForms or ASP.NET MVC.
Given Alex's answer, this should be useful:
System.AddIn Tools and Samples
http://clraddins.codeplex.com/
If you design your application for extensibility, this is easy. The Managed Extensibility Framework is designed for exactly this sort of scenario, and makes it very easy.
It will be included as part of the core framework in .NET 4, but is downloadable now for use in 3.5.
There is an AddIn framework shipping with .NET 3.5. The framework provides very powerful mechanisms to expose interfaces by a host application and to manage, dynamically load-unload addins etc.
Why the core concept that comes up to my mind first, is Dependency Injection? I haven't ever played with a plug-in system in any app of mine. Does DI could help anyhow with that??
Specifics on our senerio would be helpful, but generally, You may want to explore the provider psttern.
There are 3 components:
- An abstraction of a piece of functionality, (Interface/baseClass)
- A Factory method that looks to config to determine what type of Class to create
- [your] Custom Class which extends/implements the abstraction. for example, a Membership provider class that hits a custom dasta source for user info.
This is very useful when switching out logic. If you want to create an app with swappble UI components, it is another story.
There is support for this in ASP.NET, starting with 2.0.
More info on the provider:
http://msdn.microsoft.com/en-us/library/ms972319.aspx