.NET Web Application Portability to SilverLight - asp.net

The company where I work created this application which is core to our business and relies on the web browser to enforce certain "rules" that without them renders the application kinda useless to our customers. Sorry about having to be circumspect, An NDA along with a host of other things prevents me from saying exactly what the application is. Essentially, JavaScript controls certain timed events (that have to be accurate down to at least the second) that make it difficult to control with ajax/postbacks etc.
My question is this: how hard is it to convert an ASP.NET application to SilverLight assuming that most of the code is really C# business logic and not asp.net controls? I just got finished listening to Deep Fried bytes and the MS people make it sounds like this really isn't that big of a deal. Is this true for web apps, or mainly Win32 ones?
I know the asp.net front end is fundamentally different from SilverLight, but there is a bunch of C# code I would like to not have to rewrite if necessary. The replacement of the javascript code to silverlight I am assuming is trivial (i know bad assumption, but I have to start somewhere) since it deals with timed events, so I am not really concerned with that. I need to come up with a solution on how to mitigate this problem, and I am hoping this is a middle ground between: do nothing and watch us get pounded by our clients, and rewrite the whole application in something more secure than a web page with only front end validation. Has anyone tried to convert ASP.NET code to a SilverLight project?

If the bulk of your application is on the back-end, you should still be able to keep the majority of the code intact and only replace the front-end. However, Silverlight requires an understanding of WPF, which is dramatically different than the HTML/JS that your app currently uses. I'd say if your UI is pretty thin, it should be pretty easy to port to Silverlight, but the more business logic is in the UI, the harder it will be.

How heavily do you use the class libraries, and things that might be considered 'dangerous', like pinvoke, file system access and System.Diagnostics.Process?

Porting code from ASP.NET to Silverlight is not an easy task. As Nate points outs it depends on how much of ASP.NET application is AJAX based, and how much is based around server controls.
Silverlight is a state full client side technology, meaning everything is running on the client inside the browser. ASP.NET is a server technology, and is built around a request/response model. Since these two are completely different paradigms it's not a straight port.
However, since ASP.NET is just HTML and HTTP POST of form data people have done experiments where they have added a Silverlight application directly on top of an ASP.NET page, and manually built the HTTP POST request by hand sending back the exact data the ASP.NET application work. It's almost like doing "screen scraping" for your own application. This could work, but wouldn't be optimal. You wouldn't get a performance increase as your ASP.NET application would have to go through a full page cycle on every request.
A better alternative is to start out wrapping any functionality the user has in the APS.NET application as web services. You can add these services alongside your ASPX pages, and gradually port the application over. The UI you would build from the ground up based on these services.
Good luck!

Related

VB application invoking & directing requests to web browser

We've an existing application developed in VB 6. There are 6 - 8 modules available. In main screen, a separate button is available for each module, which on click will load the respective modules. We're in the process of migrating this to a web-enabled system and identified to go with Java-based solution.
Now instead of completely developing and migrating to Java platform, we're doing a technical feasibility study of migrating module-wise. That is, on click of 'Module 1', for example, will open up a browser instead of existing VB application forms and all subsequent handling/processing/loading/saving will be handled by the web-based Java application, which actually runs on a web/app server. Slowly this will be migrated for other modules also.
My question is, is this technically possible/feasible? That is, can we open up a browser on click of a button and direct all subsequent requests, sessions, cookies to the Java application running on web/app server. Any pointers/suggestions/thoughts towards this are really appreciated.
NOTE: I heard about WinINet API from my friends which enables to interact with HTTP protocols.
If you are moving to the "poor client" (Web) model then your back end will be creating 100% of the user interface as Web pages.
In such a case your existing rich client needs to be dumbed down. There is no point in trying to request the HTML from the server and reinterpreting it into a rich user interface written in VB6.
Thus you don't need to worry about the WinInet API (which you wouldn't need anyway since from Win2K onward you have at least 3 very nice wrapper ActiveX controls and classes at your disposal: the Internet Transfer Control, the XmlHttpRequest class, and the WinHttpRequest class).
No, in your case you will probably be stuck with replacing your "modules" (???) which probably means Forms (?) by a Form hosting a WebBrowser control.
However it will be clumsy to integrate what goes on in there with your other "modules." If that's needed you're going to probably need to spelunk the WebBrowser DOM to fish out data, inject data, etc.
Ideally you'd be moving to a Web Service model instead of a Web model. This opens a world of front end possibilities (Web, mobile, rich client) without the need for multiple back ends and is quite usable in VB6. Things have even gotten easier over time as SOAP is abandoned in favor of simpler, loosely-coupled RESTful Web Services.
What you have described is feasible to a degree, but when you start adding requirements like session cookie control it might get ugly. You may end up needing two logons in your program, one for the old/existing parts and another for the browser-based parts.
You might be better off just letting part go over to a browser and strip parts out of the old app and make people run both side by side.

Is It Performance Rich to use Web Services called via jquery ajax method in ASP.Net?

I have seen that ASP .Net Code Behind files are really slow. I have used local web services which I call from jquery ajax function and they are fast. But I am still confused? Should i display dynamic data from code behind or web services?
I let my web service return a JSON Object and I assign relevant elements from that JSON object to different html elements like (image, div etc.)
You need to weigh several things..
If you are dealing with a low-traffic, internal web application, perhaps server-side postbacks are the way to go. Often you'll find that there's less code you'll have to write in this case.
If you are working on an external, public, high-traffic web application, perhaps AJAX is the way to go. That way you avoid posting back entire ViewState and running through the full page lifecycle. This may result in more front-end code, but is less load on the web server.
Keep in mind that client-side data binding is a very viable solution these days, with the help of such things as jQuery Templates. So that helps bind data returned from AJAX calls to tables and other elements.
As far as web services go, they are great for when you're sharing data/functionality between different systems. If you don't foresee doing that for this particular application, then perhaps there's no need to over-engineer it - keep it simple with either MVC and Action methods that support AJAX calls out of the box, or get familiar with PageMethods.
I'm sure there are other pros/cons I haven't mentioned, but this is the first thing that came to mind.
ASP.NET classic life cycle and postback is the base of Microsoft Click&Go philosophy. It is not designed to be fast even if it suits in most cases.
AJAX plus Web Services architecture is good way to improve server performances and dynamicity. It may not improve client performances, may increase the network load if bad designed and complicate a website architecture.
Another possible orientation is ASP.NET MVC, where old life cycle and postback is ancient history.
Like Kon said, mixity is probably the best way at the moment : MVC+AJAX or ASP.NET+AJAX where classic client<->server requests are used for common functionnalities and AJAX requests brings dynamicity with small requests for friendly functionnalities.
Note that most users on the planet are using Internet Explorer who have the worst javascript engine on the planet ;)

ASP.NET MVC3 vs Silverlight4

Why these two tecnologies? Which are the key decisions choosing one of them? Guidelines and scenarios?
ASP.NET MVC3 provides several capabilities that Silverlight4 does not: ...
Silverlight4 provides several capabilities that ASP.NET MVC 3 does not: ...
More: what does HTML5? And ASP.NET WEB APP?
Can someone explain? Thx.
Your question is very extensive and can in my opinion not be answered without knowing what you want to do or a scenario could be.
Basically there's one important difference between the mentioned technologies: ASP.NET and ASP.NET MVC are server side technologies while Silverlight and HTML5 applications are running on a client system.
That means that you have to decide if a server application is better because e.g. you handle lots of server data that are calculated to a simple result that is transfered to the client or if you want to use a client application that usually can have a more complex UI that the user can easily use without a need of data transfer with AJAX, postbacks etc.
Of course you have to think about security, too. The more code runs on client side, the more ways exist to attack the code. Of course there are examples of server site application that are designed very unsafe but that's another point..
I would suggest that you first of all think about the result you want to achieve and then think about the technology that suites your needs.

Silverlight or ASP.NET or both?

At the moment I am starting to learn Silverlight. I have expriences in ASP.NET and like the concepts of "Masterpages. Does Silverlight provides a similar concept ? I have read a little bit about the Silverlight Navigation Framework. Is this a good replacement for "Masterpages" ?
Makes it sense to combine ASP.NET and HTML (with Javascript) with Silverlight or is it more recommandable to design and write pure Silverlight applications ? Mybe in the ner future I will start to develop an intranet (business) application which will have many and complex user interaction (it should behave like a windows client applicion). I think Silverlight is the better choice than ASP.NET !? Makes it sense also to start to use/learn the WCF RIA Services immediatly ?
Are there good (VS) templates to start with Silverlight or which are a good basis / starting point for a new Silverlight application ? Unfortunately I am missing "Starter kits" on http://www.silverlight.net like the starter kits on www.asp.net !
Thanks in advance for your hints.
Silverlight and ASP.Net are light years apart technology wise, Silverlight is closer to Winforms programming than it is to ASP.net, event though it can be hosted inside an ASP.Net page.
To achieve "masterpage" type functionality, you can have a base control or page that you can inherit everything else from. Or you can have a page which acts as a shell and you can swap views in and out depending on the user's actions.
If you are writing an app from scratch, you can do the whole thing in silverlight. You can navigate from one silverlight control (hosted in an aspx page) to another aspx page (with silverlight controls in it), but there is a performance overhead when transitioning between aspx pages (they are web pages and need to be served). You should look to eliminate separate aspx pages if possible, and create it as one big silverlight application - if your application's functionality is all rolled into one application (not spread amongst aspx pages) then you can make the most of Silverlight's Out Of Browser feature.
However you should only consider silverlight if you are build web apps or interactive/streaming stuff. If your pages are going to be largely static (i.e. presenting product catalogs, or a site where the user just drills through from one page to another) then using silverlight would be overkill, you would be better off sticking with ASP.Net or ASP.Net MVC.
Masterpages does Silverlight provide a similar concept ?
Not directly but it does provide a variety of ways to acheive the goals of Masterpages. The navigation framework is mostly the sort of thing you would need to achieve the typical reason to use Masterpages.
However its also possible to achieve "masterpage" functionality more generally by creating a UserControl that has ContentControl instances at points where in ASP.NET masterpages you would have used a asp:contentplaceholder. These content controls would be bound to custom properties added to the UserControl. This completed UserControl can then be used as the "LayoutRoot" of another UserControl or Page. Note this does not require inheritence from the "master".
Does a combined ASP.NET and Silverlight app make sense?
Well thats a tricky one the answer really is, "It depends". There are way to many factors to give this a true answer. Factors:-
Is this a public app or an internal app?
How important are including rich UI features?
First time Silverlight dev will cost you, is your project able to absorbe that?
What client platforms do you need to support?
How might ASP.NET-MVC + appropriate use of JQuery size up against your requirements?
Probably others I haven't thought of yet
Is Silverlight is the better choice than ASP.NET when there are many and complex user interactions?
The phrase "complex user interactions" could mean a couple of things? Do mean complex to deliver with HTML and Javascript but simple for the user? Or is this a sophisticated app aimed at an expert user?
In either case its likely that Silverlight will start to come into its own here.
Does make it sense also to start to use/learn the WCF RIA Services immediately?
Yet again the answer depends of the type of application you have in mind. If its line of business app where data is searched, edited and reported on then (assuming you have decided to develop in Silverlight at all) definitely you should be looking at WCF RIA Services as well as the parts of PRISM that think are appropriate.
Other types of apps may not benefit from WCF RIA Services.
Are there good (VS) templates to start with Silverlight or which are a good basis / starting point for a new Silverlight application ?
There are no start kits at present. However I think you will find what you need amoung the various demos and tutorials on the silverlight learning site.
I've particular found the videos useful. If you decide to go Silverlight its well worth clearing a day or two to got through the relevent ones.
These are a lot of questions at once.
Yes, the Navigation Framework functionality is pretty much equivalent to the Master Pages concept. Even to the point that it is tracked in the URL when users navigate, so they can use the back and forward button of their browsers.
If you want to do a stand-alone Silverlight application or a hybrid pretty much depends on your requirements and on the type of application you want to develop. If it's a Line of Business application, you might be doing fine with Silverlight alone.
For a public, content/text-intensive website probably HTML with some silverlight gadgetry here and there might still be preferable.

Visual WebGui

Hi I am looking for some web framework for my prject and I found Visual WebGui
It looks amazing, but I am pesimistic to miracles :)
Can someone more experienced than me help me?
classic asp.net vs Visual WebGui
what about speed ?
what about size of data?
what about security?
have someone personal experience with this technology?
Thanks
I have used VWG for numerous projects for the past 5 years and I can tell you that it is truly a miracle :-). I have never made such amazing web applications before. Instant AJAX, no need to ever touch HTML or CSS, and the product is constantly getting better. I know it's tough to prove that I'm a real user and not with the company, so feel free to ask me more questions, I'll keep checking this thread.
I'm not a professionally trained developer, and I don't know much about the internal workings of ASP or VWG, but in terms of your questions...
What about speed ?
-It's blazingly fast. The AJAX is faster than most AJAX frameworks out there.
What about size of data?
-The data that is sent back is compressed and kept to an absolute minimum. You can use tracing tools to see for yourself. Only required UI changes and data are sent back to the client/server.
What about security?
-It's as secure as ASP. They even had a contest for $10,000 to see if someone could hack VWG - so far, no winners.
-Danny
We've been using Visual WebGui for years with great success. Our apps require ZERO DHTML/JavaScript/AJAX/JSON/CSS coding. Seriously. For web-based .NET business applications - Visual WebGui is a perfect fit. I would highly recommend Gizmox for your next web platform.
ASP.NET
ASP.NET is a stateless dev platform. Each user's current view remains on the client - the ViewState. The ViewState must be sent to the ASP.NET server for every request This makes round-trips to the server heavy, even in AJAX scenarios. In ASP.NET, the server generates DHTML/JavaScript/CSS & sends it out to the browser. This adds to the weight of each ASP.NET AJAX call.
Furthermore, the plumbing required to wire up a real ASP.NET app, complete with JSON/AJAX/REST calls, cross-browser JavaScript, DOM management, & CSS, etc. is difficult & a maintenance nightmare.
Visual WebGui - Stateful UI
Visual WebGui is truly a revolution. Visual WebGui is a stateful dev platform, built on top of ASP.NET. All user state is kept on the server. The server knows exactly what the user's screen looks like. As such, the pipeline becomes VERY thin and VERY fast between client/server. Because the server is aware of the client's current state - the VWG Server is able to perform Diff routines - so only changes to the UI are sent over the wire.
Pipeline & Screen Drawing
Additionally, the VWG Client draws its own view. In other words - the server doesn't send out any DHTML/JavaScript/CSS... instead, the Client generates this on-the-fly based on the instructions sent from the server. For instance, to create a new Button with control ID 1 - the server simply tells the client to draw "". The VWG Client knows how to draw it's own controls. With this technology - that is literaly how thin the pipeline is.
Security
For Security, Visual WebGui is fully capable of running over SSL. Gizmox also employs a proprietary obfuscation algorithm to prevent unauthorized scripts from accessing Visual WebGui JavaScript calls & DOM elements. It works extremely well.
Application Design
Visual WebGui comes complete with an amazing Forms Designer. Modeled after the WinForms Designer & APIs - writing Visual WebGui web business apps are now extremely easy to design. Drag & drop, resize, move all your controls on your Forms & UserControls, complete with Databinding.
Two-Way DataBinding
With Visual WebGui's fully supports two-way Databinding with INotifyPropertyChanged - just like WinForms. Databind your controls to your data objects (which reside on the server) & anytime those data objects change - your controls instantly update. No need for ASP.NET UpdatePanels, etc. You don't even think about it. Just write your app & whatever needs to update on the screen - will update.
Single Language Approach - Debugging and Application Manageability
One of the core benefits to Visual WebGui is its single language approach. You write & debug ALL your code in C#/VB.NET. No more hacking JavaScript/JSON/AJAX calls & maintaining web services. No more client-side debuggers / Firebug, etc. No need to know 5 different web languages to write a single application.
Imagine - writing your app in a single language. Focusing your time on solving your business needs, not software hurdles & plumbing. Hiring & finding qualified developers also becomes much easier.
Visual WebGui instantly makes this a reality. Write business web-apps like you would a business desktop-app.
Summary
It truly is a revolution in developing web-based, .NET enterprise business applications.
I hope this helps to explain why Visual WebGui is seriously worth looking into for your next web-based enterprise business application.
Sincerely,
Ryan D. Hatch,
Customer & Visual WebGui MVP
My name is Eyal Albert from gizmox the company behind Visual WebGui.
I hope it's not to late to answer this :-) but i was referred by a friend to your question.
But i have some info for you.
The need for speed.
http://visualwebgui.com/Gizmox/CIOs/WhitePapers/tabid/528/ArticleType/ArticleView/ArticleID/390/PageID/386/Default.aspx
See the test that MVP Victor Zychla did.
Size of Data you can see our show cases.
http://visualwebgui.com/Gizmox/Showcases/tabid/358/Default.aspx
Security
http://visualwebgui.com/Gizmox/Technology/Security/tabid/624/Default.aspx
All this links are new info compared to when you asked your question i hope you find it effective.
For more info you can contact me eyal.albert(AT)Gizmox.com

Resources