We are developing a WPF/C# application and having trouble corrupt font caches. Many of our users have old video drivers which are particularly buggy in regards to the font cache. We've worked with individual users to upgrade the drivers which usually solves the problem, but the problem only comes to our attention after the user has experienced a problem which makes our software unusable (which makes it look like our bug, not microsoft's).
We use only 2 fonts in our application at the moment. Can I tell WPF to bypass the font cache altogether to prevent these problems for our users when they're running our software?
You might want to consider to not let the users with correct drivers suffer for those without.
Perhaps you can add a warning in the setup.
That said, you could stop the cache service (it is a service) but you need to be an administrator to stop services.
You might also have a look at clearing the font cache
Or you could see if delayed loading the fonts will help.
Related
Just an R&D question. We need to develop an application that can be run in a browser that has the capability of performing some system checks to gather support information to be emailed to us. These checks will include basic system information, but also will need to scan the filesystem and pull out version information about various DLLS, executables, and .NET assemblies that might be installed. The idea being that we can direct a client to a page and have the application gather the relevant information needed for support, and potentially even populate some database fields. We need it to have as small a footprint as possible.
I've worked with ActiveX before, and know it is capable of these things, but particularly on modern systems security is a nightmare to get around, with a lot of people blocking ActiveX altogether. Is Silverlight easier to deliver to clients? Does it have a lighter footprint? Is it even capable of doing these things?
Silveright has access to isolated storage, but I don't think it can do what you are looking for (I may be wrong). As for footprint, if I remember correctly, the runtime is reasonably small, and the .xap packages are limited to 4Mb.
Silverlight out-of-browser has access to the file system. http://msdn.microsoft.com/en-us/library/dd550721(v=vs.95).aspx#special_features_for_outofbrowser_applications
If you intend to run your app in the browser, you will still have to configure the trust as if it where oob. http://msdn.microsoft.com/en-us/library/gg192793(v=vs.95).aspx
However, iTunes has a neat way of doing something somewhat related. It has a custom protocol (itms://) that allows the browser to invoke a client side program (iTunes). Then you can embed html in a webpage that passes parameters as command line arguments to that app. The website also knows if the iTunes is installed by a cookie. We this in mind, you might be able to encourage your users to install some small app that setups the custom protocol on install. You could pass command-line parameters to it from the web, and the app will push information from the client back to the server.
To create a real-time experience, you could use sockets + more javascript to update the page with the info you just got off the machine.
HTH,
Silverlight runs in a pretty restricted silo and can't do a lot of low level things - such as checking the file system. So I would say it does not fit your use case, unfortunately.
My current default browser is Chrome (dev). I'm using VS2010 and Silverlight4, with ASP.NET MVC3. I don't seem to have the problems with debugging that I've seen others have. My main complaint is that I regularly have to clear my browser cache to get the latest version of my app to show up. Sometimes I have to clear it two or three times. I've taken to changing the background color of certain elements just to be sure whether I've got the actual latest changes.
Are Firefox or IE better in this regard? Is there are trick to make my latest version always appear?
Too lazy to do fiddler.
Seems I hadn't googled very well before, this article seems to be precisely what I wanted
http://codeblog.larsholm.net/2010/02/avoid-incorrect-caching-of-silverlight-xap-file
via this discussion which has other options and some useful discussion https://betaforums.silverlight.net/forums/p/11995/449355.aspx
Unfortunately, that part of my project has been on hold for a bit, so I haven't tried it out yet.
Like you, I use Chrome for my main browser, and I don't use IE for any regular browsing. But I do use IE for Silverlight development, for this reason and others. I rarely if ever have trouble with the IE cache holding onto outdated versions of my XAP file, but this happens pretty regularly with FireFox and Chrome. In addition, depending on how I closed my previous debug session, when I start up a new one, FireFox and Chrome frequently open up my previous tab(s) in addition to the one that I'm actually trying to debug. Consequently, IE is (for me) the cleanest browser to actually debug with.
This isn't really an answer -- just an observation. Sorry :-).
Have you tried investigating why this is happening using Fiddler or a similar HTTP debugging tool? Personally I've never been able to debug Silverlight in Chrome so I usually have to force IE when debugging. But I never have the problem of a stale application. I'd check Fiddler to see if you can isolate the issue. It's probably not directly related to Silverlight.
Your probleme looks like a lot like a cache configuration issue. The web server is often configurated rather aggressively concerning caching of static files, as the XAP.
So the response header are probably set in a way that maximize browser caching.
You could change the webserver configuration to prevent client side caching of the XAP file.
Don't forget to remove these setting in production, however.
Apart from the fact people get to view the app in a browser which may be familiar. Is there any actual compelling reason to use the XBAP model in WPF rather than a straightfoward stand alone WPF app.
All I can see are potential security issues and restrictions but no benefits. Am I missing something?
I have used an XBAP, once.
We needed full-trust, and we needed the application to act as if it were browser hosted. XBAP was the only real option we had, and I'm glad it was there.
Outside of this tiny nitch, Silverlight & Click Once are better all around options.
In practice No and No would be the answers to your questions. I have never actually seen them used in production nor is there ever really a justified reason to use them.
As Kent mentioned Silverlight or Click Once is almost always a better option.
One could argue, in a full trust Windows only environment, XBAPS gives you the ability to leverage the full WPF framework with the flexibility of web deployment. Of course that is what Click once is for. However, in my experience ClickOnce is a nightmare for anything more then a simple, single application install so you might argue in favor of XBAP to avoid ClickOnce headaches.
But again, my response would be, Silverlight is likely a better choice.
We use it to have a single sourced solution for an application that can run in a browser but also as a desktop application. Both full trust.
Actually a modular designed app consisting of xbap(s) communicating via webservice is very efficient. This type of scenario would allow for execution of the modular pieces to run concurrent and in separate memory spaces. This benefits the user and the application's developer(s).
The app would not run in an ie but rather a custom browser shell to control the flow and execution of the application itself. It does seem like a lot of work when everything could simply run with in a single or multiple projects but this type of solution would be pertinent in large enterprise app(s). The application Programmer(s) will be able to work on segments or distinct parts of the app which contain distinct functions, utilities, and capabilities. The user never knows or realizes that each part is actually running independently because it appears seamless. The partial trust issue is eliminated because the shell is not an xbap and has full permission. Now to the good stuff ... if there happens to be a fault (that never happens right?) other parts of the application continue to execute without failure. Try-catch-finally work great until you miss one... Last but not least no more complicate background thread processing it's in a browser and by default is async. Most systems will have multiple windows open at a time each window simply contains a browser running an xbap. Unique...Yes...Useful...Yes... It is a different approach but it is clean and simple.
Life is a race ... When you reach the finish line who will be there cheering for you and will you be proud of the race that was run?
XBAPs using Partial Trust are useful if you have a requirement that the WPF client should be run without requiring admin privileges and without installing anything on the clients machine (disregarding the user's profile cache that is)
I was thinking the same thing, here is my takeaway.
The main reason is the user experience, WPF apps are more powerful and easier to write than Silverlight. People will click on a web site, but will think twice about installing an application. An XBAP is very close to a website experience, and can out perform Click Once and Silverlight.
However since it only works for a very narrow user base, it would probably be best for intranet applications.
WPF, XBAP, Silverlight - What do I use?
Silverlight 3 can run out of the browser.. what extra functionality this offers for the developer.. and for the user?
it allows the disconnected (no need of internet connection) use of sl application + start menu shortcut + some other things you can read about here.
It allows the user to have a desktop experience without longlasting installations and with quick and easy removing of applications. The barrier to download, install and try an application is much lower, which is good for both, the developer and the user. The developer has greater chances to distribute it's application and the user won't miss a great app because it has a 500MB setup.exe and an one hour installing process.
It also allows for more isolated storage (25MB vs 1MB on the web). This will be nice for a lot of applications that were previously starved for space.
More access to the keyboard (e.g. the function keys) when in out-of-browser mode since the browser is not intercepting them.
When creating an auto updating feature for a .NET WinForms application, how does it update the DLLs and not affect the currently running application?
Since the application is running during the update process, won't there be a lock on the DLLs (because those DLLs will have to be overwritten during the update).
Usually you would download the new files into a separate area. Then shutdown and restart and at startup you look for and use the new files if found. Always keeping a last known working version on the side so that the user can revert to something that definitely works if the download causes problems.
ClickOnce is a good technology from Microsoft that does this for you and you can use it directly from Visual Studio 2008.
You'll have to shutdown your application and restart it, as other people have already commented.
I wrote an open-source code to do just that in a transparent mode - including an external update application to do the actual cold update. See http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/
The code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)
I have a seperate 'launcher' application that checks for updates via a web service. If there are updates, it downloads them and then executes my application, which is in a seperate assembly.
The other alternatives are using things like ClickOnce, or downloading the files to a seperate area and restarting the app, as someone else mentioned.
Be warned about ClickOnce, though - it's not as flexible as it sounds. And if you deploy to a system that requires elevating your program to a higer security level to run, you might run into problems if you don't have a certificate for your app installed. I found it very difficult to get straight answers on the Internet to things like certificate management when it comes to ClickOnce. If you have a complex app, you may want to just roll your own updater, which is what I ended up having to do.
If you publish via ClickOnce, all of that tends to be handled for you. It has it's own pro's and con's but usually easier than trying to code it all yourself.
Both Wikipedia and 15seconds have decent info on using ClickOnce, how it works, etc.
As others have stated, ClickOnce isn't as flexible as rolling your own solution but it is a LOT less complicated. It has a small learning curve at first, but with pretty much everything bundled into Visual Studio and the use of Wizards, it usually doesn't take long to stumble onto a working solution.
As deployments get more complex (i.e. beyond than just having prerequisites or application code that needs updating) and you need to do a lot of post-install or pre-install tasks, there are things like WiX which give you somewhat of a hybrid solution between Windows Installer and ClickOnce, with the cost of flexibility being a much steeper learning curve.
The only reason I try to avoid custom installers is that you end up spending way too much time trying to get it just right to handle a bunch of different "What If" scenarios...
These days Windows can do such updates automatically for you with AppInstaller if your app is packaged in the MSIX package.
It downloads the new version of the app in another folder inside ProgramFiles\WindowsApps, then when a user runs the app via the start menu, the system knows what folder it should use. The previous version gets deleted when not in use.
If you want to know how to package your app this way I collected my findings in this answer.