Consider any WPF app, targeting any .NET version (including .NET 5). On application load, nearly half a second is wasted in reading/parsing of AppSettings.
Q: Is it possible to completely disable the AppSettings system in a WPF app?
As can be seen in BaseCompatibilityPreferences.cs the AppSettings object is hit immediately upon type initialization (static constructor). This is where a performance hit can be observed:
I can imagine that an antivirus scanner could be involved here, since this involves reading from disk. Anyway, I'm wondering if we can completely get rid of this cost. Ideas?
Related
Recently I developed an application using a Pivot control as a "menu" and other pages with XNA content (2D and 3D).
Now, I discovered that my application won't be certified cause Im using System.XNA.Framework.Game and System.XNA.Framework.Graphics in my app.
This is really upsetting me at the moment, cause it's throwing away hours of work...
I never published something on the marketplace, so I'm asking if it's possible, anyway, to publish an application of this kind or at least, publish it as Beta Testing without "Certification" as they say on few pages..
Any clue?
Composite Silverlight+XNA applications are different from full-featured Silverlight applications invoking XNA assemblies. The restriction is still there - you must not have calls to Microsoft.Xna.Framework.Game or Microsoft.Xna.Framework.Graphics.
Mind you, some XNA elements are still allowed, such as Microsoft.Xna.Framework.Audio, that gives you access to the Microphone class, or Microsoft.Xna.Framework, that lets you access the FrameworkDispatcher.
Given that C# is a leans more towards a strongly typed language, why did the designers chose navigation based on URIs over Classes?
NavigationService.Navigate(new Uri("/MyPage.xaml", UriKind.Relative))
fails at run time if MyPage is missing.
If there were a method that support passing a PhoneApplicationPage as a argument like
NavigationService.Navigate(new MyPage());
Navigation related errors can be caught at compile time.
Why was this not an inherent design in Silverlight/WP7 ?
Only the WP7 dev tools team can say for sure, but absent their input, I'll give it my best shot. My guess is that it arises out of using a plug-in framework for client application development. Web Silverlight doesn't even really have the concept of navigation. You can switch frames in and out of the applications main frame, but that's not really navigation persay. So, when they were asked to use Silverlight as a client application tool for WP7, they had to decide how they were going to navigate around.
The most obvious way to solve the navigation problem, if you're a team that's been building internet applications, is to make something as close to the internet model as possible. This allows developers to carry internet applications to the browser and do minimal rewrites of their code. Think about it, if you had a web application that used relative URLs to move between application pages, your WP7 could reuse most of that navigation logic with only slight modifications to use the new NavigationService. This also minimizes the changes from core Silverlight that the WP7 version has to make, making everything easier to keep synchronized between platforms.
It obviously isn't the best way of doing things, and it makes state maintenance between pages a royal pain in the ass, but I can at least see why they decided to do it this way. The main flaws, in my experience, are the runtime checking of navigation destinations (instead of compile time with classes), passing parameters (every page needs an OnNavigatedTo that parses out variables) and maintenance of non-trivial objects between pages (I've taken to just using Singletons to hold relevant objects as a sort of poor-man's cache). I'm hoping for at least some modification to the navigation paradigm in 7.5 or 8, but I'm not holding my breath.
This navigation model was inherited from Silverlight on the desktop (and WPF before it). It's important to note: this is not a String-based model, but rather a URI-based model. The difference here is key: we're not talking about an arbitrary string to point to some XAML, we're talking about a universal locator for a resource that is a page within the application. By addressing navigation this way, your application actually has more than one entry point -- any URI within the application can be a valid entry point. And by making navigation URI-based, you ensure that the "state" of your application as it relates to what you're looking at can be serialized, accessed at any time from any direction, etc.
Imagine, for example, that you have a link on a webpage (or in an email, or anywhere else) that you want to open in your application. Click the link, and because the URI fully describes the resource that the application should display (e.g. an item in a catalog, filters on a search, etc.), you can jump straight to it (a.k.a. deep-linking). This isn't implemented on Windows Phone 7 (at least not from other apps, but it's really how the back button, etc. work), but the model comes straight from Silverlight on the desktop (the Navigation framework is in the Silverlight SDK), and you can see where they might take it on Windows Phone in the future.
Again, the power of the URI is its universality -- it is a common way to identify a resource. Without it, you're stuck with a tight coupling of anything that wants to navigate into your application and the application itself.
Silverlight/WP7 navigation service is fairly lacking in many regards, but there are a fair number of frameworks around that allow you to navigate to the ViewModel/View. Some examples:
Windows Phone MVP
Columbus
Xamling Core
In Caliburn Micro (MVVM framework) you have a nice way of handling navigation using only ViewModels - "Screens, Conductors and Composition"
Also keep in mind that using frames you can use routing in Silverlight to map one or more user-friendly URLs to the same .xaml file. If you would specify only the view class then Silverlight wouldn't know to which URL to map to.
Passing query parameters for state managment might be ugly, but it allows your application to be stateless which has some advantages (e.g. deep links) and fits the stateless nature of http web applications.
Way back when I built an internal site for a customer using silverlight 2. They've been happy with it and I've barely had to touch it. Is the expectation that this site will always work? What I'm afraid of is suddenly getting a call years from now that the users installed silverlight X and now it's broken and I'm going to have to convert it immediately past Y versions of Silverlight to get the site back up, and I don't even do Silverlight anymore.
I already went through this once when it went from 2 beta to 2 release and and scrambling to fix all the breaking changes and get the site back up. It wasn't as big a deal then as we were in beta anyway.
I could upgrade now but it would be really tough to go back to the customer and ask for money to do an upgrade when they are happy now and will see no noticeable benefit from staying current. Additionally there are some third party controls that would have to be licensed again.
So I guess what I'm asking is there a known end of life? Or do we just play it by ear?
Based on the Silverlight Support Lifecycle Policy, it looks like official support for Silverlight 2 has already ended (as of October 12, 2010). However, some other documents (mostly listed at this SO question) give the impression that Silverlight apps are binary backwards-compatible through a sort of Silverlight "quirks mode," so as long as you're not changing your Silverlight app and the policy doesn't change, the app should work indefinitely.
The folks at MS have so far done a reasonably good job of maintaining backwards compatibility between Silverlight releases. But there have been some significant changes, and depending on what your app does, what features it uses, and what bugs in the runtime that it takes advantage of, it may or may not continue to run cleanly on future versions of the runtime. MS gives some good examples of the breaking changes between Silverlight 3 and Silverlight 4 here.
One example of many: Silverlight 4 introduces a new "Watermark" property on the Textbox class. It's possible that a Silverlight 2 or Silverlight 3 application subclassed the Textbox class, and added their own Watermark property. References in XAML to that Watermark property could thus throw an AmbiguousMatchException when executed on a Silverlight 3 or Silverlight 4 runtime.
Presumably there will be more changes of this sort as MS moves to SL5 and then SL6, and so forth: and their dev team will stop worrying quite so much about breaking SL2 applications. A change that introduces a really cool feature but breaks some reasonable portion of SL2 applications would presumably be unacceptable in SL5, but maybe not in SL6 or SL7.
My recommendation in your specific situation would be to let your customer know about the possibility of future issues now, so that they have a chance to make a decision about it when it's not an emergency.
Take it easy :) It would allways work.. Silverlight have 100% backward compatibility for EVERY major version!
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.
I need to convert an existing WPF project to Silverlight. I know that there is no an automatic way of doing it.
Could you share your experience and give advise regarding steps for this conversion and what pitfalls one should be aware of?
Considering that Silverlight is a subset of WPF, there are many potential issues.
First I would ask why you want to do this, since generally they are used for different purposes. That being said, if you are determined to do a port, then you need to do a namespace analysis to validate that all of the namespaces you are using in your WPF app exist within the silverlight runtime. If you are using things not supported in SL, then you are going to be spending quite a bit of time re-writing those portions.
Other issues I know of are that Silverlight 3 runs in a sandbox, so you can't use the disk, hardware on the box, etc. You also are limited with regards to any requests made over the network, as they must be back to the hosting domain, or use a cross-domain policy file.
Silverlight 4 brings more parity to the party, in that it allows you to run as a trusted desktop app, and brings more of the WPF functionality in, but still not equal.
Kind of a hard question to answer without further detail, but this should get you started.