I've been asked to do some work on an existing Silverlight project, mainly extending it a bit and doing bug fixes as needed. But there are a couple of ASP.Net pages too and a WCF service to deal with too. My background is desktop development with .Net so I think this is a good opportunity to start getting more involved in Web development.
So I'm trying to figure out what background knowledge I need for a project like this. Clearly I need to get familiar with Silverlight, but I'm not sure what other Web technologies, etc I need to ramp up on for this project. Obviously I would like to know as much as possible but in reality with limited time and resources I really need to focus on what I important in the near term for this project. Then expand my knowledge as things arise.
The things I'm thinking that are important in the immediate future are:
The basics of Web Development (I'm thinking this might be the most important\fundamental area to build a good foundation)
But what are consided the basics?
What is technology\language independent?
What is important for Silverlight?
The basics of ASP.Net (since there is some ASP.Net code)
What are the basics? ASP.net seems so huge, I have a 1000+ pg book here which seems daunting.
If you focus on Silverlight is knowing ASP.Net important, or is ASP.Net something I will continually run into?
How does ASP.Net MVC fit into the overall development picture and especially as related to Silverlight?
The basics of WCF
As compared what?
Any suggestions\comments on the list above?
What other topics\technologies will I run into if I continue doing Web development?
Note: Beyond this project I would focus on the Microsoft stack.
Generally speaking the amount of knowledge of ASP.Net you need to do Silverlight development is very very low.
Silverlight applications are hosted in a browser, usually via the <object> tag. This can sit on an asp.net page or a html page. The Silverlight template creates that for you, so you can forget its there and just get on with the Silverlight app.
Of course if you are integrating into an ASP.net environment (for example, islands of Silverlight sprinkled through an ASP.net site) then thats another thing. There are ways to get Silverlight talking to the HTML dom via the HTML Bridge but its not necessary. Really depends on what you are developing and integrating with. (new site vs existing)
I avoided ASP.net for as much as i could as the richness compared to desktop (WPF) just wasnt there. Silverlight changed all that. Its a Rich world on the web now!
Best place to start learning Silverlight is www.silverlight.net on the getting started part of the site. great Quickstarts and tutorials there.
Good luck
Only cursory knowledge of traditional web technologies (css, html, js, etc.) are necessary for silverlight development. As a consequence, you also don't need to understand the many cross-browser dependencies as well.
Here is my list of things that you must get a really good understanding of to be proficient at Silverlight development:
Understanding WCF (the Silverlight-supported parts) is essential. It can be a configration nightmare, but once working it is pretty stable/ reliable
You need to understand serialization used by WCF and how to debug the mysterious 404 errors. Get good at Fiddler and/or Firebug.
You must understand multi-threaded applications and how do debug them. Silverlight makes extensive use of threading to not block the UI thread. This creates numerous opportunities for race conditions that create what appear to be "magical" results. That said, it is incredibly powerful and IMHO one of the dominant reasons to use Silverlight.
What you learn about serialization and WCF will ultimately help you cache some data in IsolatedStorage. Learn about IsoStorage, it will reduce our bandwidth requirements and cost and improve your user experience
Learn about Linq - again this is one of the most powerful features of Silverlight. Combined with a smart client-side caching strategy you can offload lots of processing to the client.
Figure out how you going to support printing. SL3 does not at all and you will need a server side component. SL4 beta does, but it is not go live
Understand the Silverlight Roadmap as much as possible and plan out your roadmap to match/ sync with it as best as possible. I first built a SL2 app and I spent a lot of time building things by hand that were ultimately released in SL3. As it is getting more mature, there is less of this.
Download the Silverlight Toolkit and use it. But more importantly examine the source code, the structures, its build process. There is not better real world place to look for inspiration & best practices.
Good luck.
Related
My team is working on a strategy to convert our cloud based Silverlight app to HTML5 app. Although we have been working on formulating a strategy to find best possible set of tools, technologies, and methodologies to convert our App to HTML, I am asking this question here to get some feedback from the large community at SO and to learn from experiences of the people who may have done similar things in recent past.
My question has a few parts.
Our app is written in Silverlight and uses WCF RIA services. Most importantly, we rely a lot on MVVM and we wish not to rewrite that logic again hence to reuse as much code as possible. What would be, in your opinion, the best possible combination of tools and technologies for us to use?
In order to make SPA, we would like to use some of the “cool” new frameworks out there but we really want to minimize our work (due to hard deadlines) and be able to thoroughly test our app easily and quickly (hence the code reuse). Is SPA even a good option or should we go for traditional MVC app? Keeping in mind that there are more than 200+ views in our app.
If we chose to go the SPA route, which framework is best suited in terms of life span. We have to move away from Silverlight because it is going to die soon. We don't want to be in the same situation again in near future.
Moving an existing Silverlight app to and HTML5 web app is the perfect project for AngularJS. Angular has it's own similar MV* design pattern, but you will not be "reusing" code from your existing silverlight apps. The main ideas and abstractions may be similar, but just the nature of how html and js work together, and especially how they work in angular, you have to do it the angular way.
Also, Angular is somewhat of an engineering approach to web development. It is not a learn-it-in-a-weekend piece of cake framework to master. There's a lot that goes into it. There's noob ways to do things in Angular, somewhat noob-ish ways to do the same things, and then the so-called "right" way of doing it so you may find yourself learning some ways of doing things only to have them replaced with "better ways".
If you want to "minimize your work" then Angular might not be the best choice, but if you want your HTML5 app to be really awesome then any framework you with will require some studying in addition to getting used to the inherent quirks of Javascript.
Angular 2 is hot and just launched a Beta release, but I'm still happily using AngularJS 1.4 for all production apps.
After 9 month developing an enterprise application using MVC + JQuery our Management and stockholders interesting to convert and switch to silverlight! they think it's more powerful than Ajax, make development speed faster than our current solution, It's Windows and Web and less headache.
Unfortunately, our stockholders dos not know anything about web and stateless state of web application and they always compare with window applications.
But nobody in our team know anything about silverlight. I am not sure that is a good decision. I think we develop as fast as possible. we develop a great framework and code generator for fast develop.
Thanks and sorry for bad English.
Dumping what you have and going for a rebuild mid development is almost always a bad idea.
For a personal project, I did exactly this. It was originally built during the betas of asp.net MVC. I got the app to a stage where it was usable (actually I still use it daily), but it was nowhere near ready for the outside world. And this was the problem; it was going to take an enormous amount of work so that other people could use it...
When Silverlight 3 was announced, I literally grabbed the backend of the app - stuck RIA services in between and had a few screens up and running that day without any prior SL knowledge. I probably could have kept going down this path but something clicked when I started to realise the power of silverlight. The goal posts for my app moved, and I began a SL specific rewrite.
Since then, I've started re-writing about 5 times over. I guess I'm still just learning how to best build an app in SL, having spent the last 12 years or so of my career working on stateless web apps, there was a big mental shift involved.
I'm a much better web developer then I am a silverlight developer, but if it was for a real project (rather then a pet side project) - it would have been shipped and out the door by now.
I'm convinced that SL is the ideal platform for most web applications (as long as it being a plugin isn't going to be any issue).
With that said, shipping is still the most important thing. SL is great, but the learning curve is steep. If you guys are anywhere near completing the app, I'd insist you forge on with mvc and maybe get someone to build a SL branch.
Re-platform an application is always costly, although if you've got your MVC right it should theoretically be easier to replace the "VIEW" part of the application with something else.
As to whether Silverlight offers you more than HTML / JavaScript is down to what you're using it for. If what you are doing is media-related or highly graphical, Silverlight might be a good choice. If your application is like most business apps (i.e. some input fields backed by some read / write to database) Silverlight doesn't really offer any tangible time saving for this kind of operation.
If the web application is public and you care about search engine indexing, semantic HTML offers the best possible option.
I absolutely have no idea about Silverlight except that it is a Microsoft technology.
Having nearly completed a Computer Science degree, having programmed in C# for a few years in a work environment - have a good knowledge of Java and OO techniques - how hard is the road of average Silverlight programming? I've been offered some work DAMN IT!
I've mucked around with PHP, HTML and nearly no CSS..
Would I need a strong web programming background in order to pick it up?
I like Ben's answer, and he's right that a huge bonus of learning Silverlight is that you don't have to worry about the stateless model. However, there are a few parts of Silverlight that are less easy to learn:
Styling & control templates - These concepts look like CSS at first but there's a good bit more that you can do with them such as completely overriding the visual aspects of the control. Also, modifying the styles of existing controls is one thing and learning how to create your own control that can be easily styled is quite another.
Database connectivity - If you're anything like me the first thing you'll want to do after you write a "hello world" test is hook up to a Db and pull down some data. Since Silverlight can't directly connect to a Db you'll have to learn one of 3 techniques to move data between the browser and server: 1. WCF + your custom service methods + LINQ to SQL or LINQ to EF or whatever data access you choose. 2. ADO.NET Data Services (great way to start out) 3. .NET RIA Services (once you've realized that you need your data access technology to play nice with data binding and honor biz rules).
Security - You need to learn another part of the MS technology stack to get this working properly, ASP.NET Application Services. It should take more than a few hours to hook things up but it is another technology to learn.
Browser navigation, search engine friendliness & deep linking - Things you take for granted writing a traditional web app will take a bit more work in SL. You can use .NET RIA Services to handle browser navigation & deep linking, others have written about making your site friendly to search engines (and I don't know how ;).
What I'm trying to highlight here is that while learning the basics of Silverlight is easy, you'll probably run into other parts of the MS technology stack that you'll need to learn to get your work done. The beautiful thing here is that all of the technologies come from 1 vendor with a single focus and they work really well together. I shudder when I think about all the different technologies you'd need to pull off my current SL app in the open source domain.
Pick up the book "Silverlight Unleashed" and go to http://silverlight.net/GetStarted to start learning. Scott Gu's 8 part blog posting (#3 on that Getting Started web page) was one of the first things I read about Silverlight and is hugely helpful.
Unless your Silverlight app has to interact with a traditional web page, you don't need to know anything about traditional web UI technologies.
If you've done any desktop UI development you'll find Silverlight much easier to pick up than any web UI paradigm. Compared to the unholy mess that is css + html + javascript combined with ever-changing browsers and fourteen other hundred-author web "standards", Silverlight is a walk in the park.
First I'd like to make it clear, I'm not looking for a "my tech is better than yours" type of post; this is a real case scenario and I have been faced with this decision. With this in mind, let me explain:
We have a WinForms application. It started in the early .NET 1.0 but the first shipping version was using .NET 1.1. There are layers (like BusinessLayer.dll, Datalayer.dll, Framework.DLL, etc.) but at some point during the "long" development cycle of this application, the "presentation" layer (Win Forms) got infected with some code, thus the "separation between the code and the presentation with code behind" is some sort of myth.
Bad practices or whatever, the truth is that the application is there and it works.
Years passed and we had .NET 2.0, we slowly migrated and it mostly worked, had to change a few calls here and there. Last version did the same thing, but for .NET 3.5sp1. We needed some sort of Webservices thing, and decided to use WCF instead. It works fine.
But despite all these .NET upgrades, most of the application's codebase is still the same old rock and roll from 5 years ago. We use Gentle.NET (old and unmaintained now) for our dataobjects (it was a blessing 5 years ago!).
Our presentation layer, the winforms, are "nice looking" since we employ 90% of completely gdi+ custom controls. (whenever possible without having to hack the WinAPi). The application is touch based (i.e.: it makes use of the Ink but it doesn't rely on that), but the buttons, labels, etc, everything is "designed" to be used with a tactile device. (TabletPC or Touchscreen). Of course some users use keyboard/mouse.
With all that in mind, and with all this web2.0 and Internet fuzz (plus Jeff's posts ;) ), we are considering the possibility of rewriting the application but using a web technology.
The idea is obviously bringing more availability for our customers (they can use the system whenever/wherever they want), and less maintenance (we can upgrade and it is an instant upgrade for 'em all), etc. You know, the usual Internet vs WinApp thingy.
The problem is that given that this is the healthcare industry, not all of our customers might be willing to "move" their databases to our server/s, which is acceptable, and would force us to install a webserver/database server in their own servers so they have their own copy. Not a big problem (except we would have to update those manually but that's not an issue, given that we've been updating win32 apps for 5 years now!).
Now, back to the main "question".
The team has little Asp.NET experience, we did program a lot in ASP 2.0 (in 1999/2000) but that was a spaghetti of HTML+VBScript+CSS, so I don't think it counts. After all that experience (the Internet bubble!) we went back to VB6 then C#.NET 1x and you know the rest of the story. We're a small team of C# developers for WinForms. We've acquired some Linq To SQL Experience in our last .NET 3.5 ride, and we liked it. We felt it very natural and very "if we would have had this five years ago…" like.
Given all this, rewriting the application is not a "simple task" (not even if we wanted to do it in the already known C#.NET), it would take time and planning, but we could correct dozens of mistakes and with 5 years of experience working with the application, we now can say that we have a better idea of how the customers would like to use the software and what limitations we created (by ourselves) when we designed the current app.
All that "knowledge" of the application and the way the business works, could be applied to produce a much better application in terms of design and code and usability. Remember in .NET 1.1 we didn't even have generics! ;) (you'll see lots of ArrayList's hanging around here).
As an additional note, we use Crystal Reports (and, as usual, we hate it). We don't think the ink control is a "must" either. The HTML/CSS could be shaped to look the way we want it, although we're aware that HTML is not WinForms (and hence some things cannot be reproduced).
Do you think that planning this in MVC (or WebForms) would be too crazy?
I like the MVC (ruby on rails like) idea (I've never programmed in ruby beyond the basics of the book), so no one in our team is an expert, but we can always learn and read. It mustn't be "rocket science", must it?
I know that this whole question might be a little bit subjective, but would you replace an aging Winforms application with a new ASP/MVC/XXX web application? Do you have experience or have tried (and had success or failed) ?
Any insight in helping use better decide what to do will be appreciated.
Thanks in advance!
UPDATE: Thanks to all who responded, we'll evaluate whether this is a good move or not, it sure is a hell of work, but I am afraid the the desktop app is getting older (using old net 1.1 hacks) and tho it has been more or less working without problems in Vista and W7, I'm afraid a future update may break it.
Also, lots of "more or less core" parts of the application are exposing some badly designed ideas and we had to hack here and there to accomplish certain tasks. Part inexperience, part lack of 100% knowledge of how the business worked (and Customers not sure what they wanted).
A new application (in any form) would allow us to create a better foundation while retaining all the user knowledge.
But, it's a L O T of work :) So we'll consider all these options here.
As some of you have mentioned, maybe a thinner client and some (ab)use of WCF here and there might be more appropriate.
Once again, thanks to all!
It would be best to ditch all your efforts of reusing the desktop application code when you recreate the web app. Following are the reasons:
Web apps especially asp.net use a different model. For starters note http is stateless. Each time the browser talks to server you have to explicitly send the current content of all the controls on the current page. You would not have used such a model in your Windows application.
To decrease load on the network you want to optimize the size of viewstate and how frequent you make http requests. Again your existing window app does not have any such provisions.
Updating view. You might have different event handlers, threads and what not in your windows application to update the GUI in different scenarios. All of that will need to be replaced. Javascript is a totally different animal.
Security. When using a browser your access to the local disk is highly limited whereas you will take the same for granted in windows application. If there is any code in the windows app that requires local resources, then that is going to be a trouble spot for you.
I would recommend the following:
Verify if your current application has any local disk access requirements (e.g. read/write to local file etc).
As you write the different http modules or handlers, you can try leveraging some of the backend/ business logic part of the existing windows application.
Give some thought to what part of your application can become a web service.
It sounds like the application needs a lot of refactoring to clean it up. If you want to move to a web model, and have maximum reuse you will really need to do that. Before you move to a web model I think you need to understand if it will be possible to replicate your user interface in that model. Is it your unique selling point from a customer perspective? You want decisions like this to be user driven rather than purely technical decisions.
It sounds like your application is the perfect candidate for a thick client application, rather than the lowest common denominator web model.
Some things to consider:
How will the web interface impact the Tablet interaction?
What new customers will having a web version bring you?
Will existing customers abandon your product?
Do you have access to consultants or outside resource with the right skills to mentor you in web technology? If you don't you can rely on StackOverflow or other web resources to help. You need some good mentoring and guidance on the ground with you.
What happens if you start this effort and it takes much longer than you expect? You know the app but don't sound like you know the web. Past experience shows that massive rewrites like this can end in disaster (it never sounds so difficult at the start)
Can you possibly write new features in a web-based version?
Could you move to ClickOnce deployment to make the application easier to deploy to customers. One of the benefits of the web is easier (zero) deployment. Can you get closer to that?
Would it be easier to migrate to WPF and create a browser application with that?
Silverlight or Flex might be better options for creating a rich experience, and may be more approachable for WinForms developers. Is this a possibility?
It seems like your app. is one of those that works best as a desktop app. Though you want your users to be able to access your app. using a browser.
I would suggest refactoring as much as possible so that the GUI gets cleaner and don't have "code".
When you've done this, start developing a asp.net mvc app but keep your desktop app. You should be able to use all layers except the UI layer, making it easier/faster/... Now that mvc exists, I'd say webforms is more about letting non-web devs do web. But you know web, sort of, and you want control so mvc is the way to go.
We are developing/mantaining an enterprise application which for historical reasons and development speedup it was targered for WinForms.
Now we are thinking that sooner or later (more sooner than later) that application will need to be Web based.
Thinking on the "to-Web" movement. Which are the most important things we have to consider? Something like, thing on MVP parading (or others), determine now the kind of platform/framework you are going to use, ...
Any experience on migration from winforms to web? Any suggestion to take care?
Aclaration: In our scenario the application would be nice NOW to be Web based but we are realistics. I agree that not all the applications have to be Web based (this is the main reason we developed with WinForms!). But sometimes the requirements changes and, in our scenario, we want to offer that application as SaaS.
The main thing is to completely separate the user interface from everything else. Once you've done that, you won't be rewriting the application in order to port it - you'll just be creating a web UI on top.
NESBAWA (Not Everything Should Be A Web App).
I worked for a company that went through a similar situation with their monolithic WinForms application. From that experience, there are two things to consider:
1] Decouple all data access logic (DAL) from the existing WinForms UI. You can start this process before any web development begins.
We did this refactoring in a series of 6 weekly sprints. Some parts of the app were easy to change - others were made of completely hellish spaghetti code that interwove DAL, inline SQL and UI code all in the code behind of the WinForm.
Once you have this separation in place, supporting two different UIs is easier.
2] Ignore ASP.Net MVC and target WebForms. WebForms was designed to make writing a web application close to the experience of writing traditional WinForms UI code (event driven, component based).
You need to understand the page lifecycle, and there are a few conceptual gotchas around dynamically generated controls that tend to trip up a lot of newcomers - but otherwise it's the most painless way to get a team of WinForms developers doing web stuff. MVC maybe very popular in web circles right now, and it provides a better separation of concerns (though you can achieve similar results with WebForms with a bit if diligence and strong design leadership) - but it requires a higher degree of knowledge. With MVC you're working closer to the metal of the HTTP request/response cycle. WebForms abstracts away a whole lot of that for you.
Best of luck in your endeavour!
John is right.
However, have you heard of the "Empty Client" approach? This is a fairly new approach to developing .NET WinForms applications that can also run as web applications on plain browsers. That approach would allow you to develop your WInForms application and put it on the web if and when you desire with no additional development or adjustments.
One framework that does it is Visual WebGui