I have a small windows forms application that I'm currently distributing via clickonce. I'm finding that I have a lot of hoops to jump through to get the click once installer branded with my logo via an automated build and am thinking about going with Squirrel for distribution as it seems to offer more control over how updates are performed.
I was wondering what other alternatives there might be that I'm not seeing. What is the standard mechanism for distributing apps that will have somewhat frequent updates.
Related
I've been developing a windows store application for a windows 8 tablet (Microsoft surface). So far the application has been designed using XAML-RT/C# using a SQLite database. The application won't be released via the store, it'll be just used internally by my company.
I am however finding numerous problems with the platform. i.e. speed of the surface device, releasing versions and renewing the developer licences.
As the application is still in the development stage and no decision has been made on the final tablet I'm thinking about re-writing the application using WPF and using a full windows 8 tablet (not a RT/ARM version). This way I can use full SQL and have much more control over releasing the software.
So, my question is...
What is generally the best development platform for a full windows 8 tablet? Is it best to go with WPF or stick with the Xaml for RT?
Thanks
WPF
less sandbox limitations (can call any APIs)
is currently somewhat easier to do enterprise deployment with
has more features
is more mature overall
can benefit from Surface SDK 2.0 controls for great touch support on big screens
WinRT/XAML
works on ARM devices
is lighter and faster
has built-in modern touch-enabled controls targeted for tablet use
might be better suited for use on tablets overall
Overall the main benefit of WinRT is that you can use it on ARM tablets which are cheaper, lighter and more usable as tablets. WPF requires heavier devices and might be slower, but you gain the ability to access all legacy APIs.
If you intend it to be fully touch screen ready then you'll have to do some extra work in WPF to get the level of UI interactivity that you get from the "metro" apps.
That being said, if you're writing a complex application that requires lots of API calls/web services and file handling then you're going to have a much easier time with WPF.
Looking for opinions. I'm working on a mid-sized 3-tier ASP.NET project (.NET 2.0 and Visual Studio 2005) with an Oracle on Unix back-end, some beefy MS web servers, and IE browser clients. Performance is pretty bad, and users feel the UI looks outdated as well. We may have an opportunity soon to redesign and rewrite the entire application from the ground up, and I'm wondering what the current or recommended MS platform is.
I was involved with WPF and Silverlight on a different contract when MS downgraded support for Silverlight in favor of "HTML5" for Windows 8 and Windows Phone a few years back. I'm not trying to start a flame war between how long Silverlight or even WPF will be around, but I'm looking for some modern alternatives as of today, April 2013. The one requirement we can't get around is that we can't install something on each and every user PC throughout the client organization.
My own background is in WinForms and C# more so than any of the above, but everywhere I turn it seems developing any new LOB apps in WinForms isn't done much anymore.
Whatever happened to the Application Server platform and apps run thru Remote Desktop? Does it still make sense to develop desktop apps and deploy to app servers and just put a shortcut on each user's desktop, or even map a drive letter like we used to do back in the day?
Your $0.02 would be appreciated!
I would definitely consider doing it as an internal web site.
The UI would be HTML5 using the "single page application" (SPA) for each function you need. Each function would be on a page that is loaded when the user needs it. The javascript/ajax code in the browser would interact with the web server which feeds back the raw data needed to be displayed.
Using Active Directory, you can have full security and customization per person.
If you need lots of interactivity, then you'd also want to consider including SignalR in the mix. (That is one of the "new" MS tools!)
If you can't install anything in the end users' PCs then go ASP.Net. Anything else will require installation.
You can make a web application more appealing to the users by having a good designer and a LOT of javascript. Not remotely comparable to the power and beauty of WPF, but that's your best bet.
WPF is part of the .Net framework and will not run without it installed.
Silverlight could also be an option, but it still requires an installation (although minimal, 4 MB, less-than-2 minute install), but an install anyways.
WinRT only works in Windows 8. It's not supported in lower versions (Vista, XP, 7). So I don't think it's an option as of now (unless all your users have Windows 8, of course).
And no, winforms is not an option. It's also part of the .Net framework, and even if you could get it installed, it doesn't make any sense having to deal with the limitations of it, having many much much better technologies at your disposal.
I have a customer who wants an application for his travels where he can update an online DB, he doesn't want to buy a laptop, he wants a tablet or something similar. I have no knowledge nor desire in creating special apps for mobile devices, I want to create a winform just like I always did when it was targeted for pc. Tablet pcs (which from what I understood is just a regular pc?) are still very expensive in my country.
Is there a simple adjustment to make winform app run on a tablet with android or I have to build a special app for it? Any other solution? (I began in writing a web page for it, but it's much easier using winforms)
Native WinForms applications will not run directly on Android (or any non-Windows platform). You may want to begin by looking into MonoDroid for porting .NET code Android (and Mono in general for porting .NET code to non-Windows platforms).
A successful port across platforms will require that the application be structured in a very de-coupled manner. Core business logic in the abstract part of the application should be easily ported, but concrete implementations (specifically views and data/service access) will require some re-implementation for the different concrete platforms. So the overall architecture needs to be very de-coupled and pluggable.
Is a Windows tablet an option? Using various new technologies at Microsoft (Windows 8, Metro UI, etc.) you could build an application that would target multiple Microsoft-based platforms. This could easily satisfy the requirement of being "a tablet" (if the requirement isn't more specifically "an Android tablet"). However, it won't be the old WinForms style of applications.
In general you'll find that the industry has been steadily moving away from WinForms for, well, this exact reason. It doesn't port to other platforms, and there's a wide variety of platforms in demand today.
Forget convertion i was in a similar position years ago and i did something easier faster and i think smarter.
just make a winform with nice big controls take care of docking scaling anchors etc so that it will look nice and can be used with small smart devices.
Make sure you pass some start program parameters in your app and when a special parameter is passed instead of opening the main typically desktop form of your app open that new one in fullscreen.
Now the tricky parts isnelsewhere. I hade setup a tiny windows 2008 r2 server that allows remote apps to be run on it.
Create a user account that you will allow access to that server and only that app of yours with the specific parameter we talked about. (Ex myapp.exe -remote)
The what ever device he will get you can download the free app like 2x rdp or microsoft rdp in android. Make a new connection to your server (you can use any free ddns you like if you dont have a static ip) and connect with that windows server account you did before.
This account if has been properly setuped will only run your app and will only show that new mini winform you did..
The end user will do a simle click and from his internet connection will do a simple remote desktop that is linited to your app only. (Router configuration is needed once)
That way you will keep maintain just one source code and he will have low bandwidth cost and can continue his work without data loose in case of disconnection.
I use that for years in mobiles tablets and pos systems. Its fast its stable its secure its easy to maintain (nothing on the client side) and you don't waste months of learning wpf or doing xamarin converting.
I have been using WPF for a while, and I keep on realizing again and again that Microsoft invests its efforst in Silverlight, not in WPF (RIA Services, default theme, controls and more).
I thought it might be a good idea to migrate to Silverlight (i.e. creating standalone desktop apps with Silverlight 4.0), the question is whether this is possible or not.
BTW, I think LightSwitch applications are generated with Silverlight as standalone desktop apps.
From MSDN:
Silverlight 3 applications are no longer restricted to running in a browser. They can be run in a browser or it they can be detached from the browser and run from the desktop. These out-of-browser applications allow you to bring the richness of Silverlight 3 applications directly to the desktop without the restriction of running within a browser.
Link: Building An Out-of-Browser Client With Silverlight 3
It is possible to create standalone desktop apps(Out of browser apps) with silverlight version 3.0 or higher and it works great. Now it is also possible to install the out of browser app even without opening a browser as shown at this blog post .Silverlight is awesome and silverlight apps even run on MACs and Linux(limited support)
However, it is not true that Microsoft is only investing in silverlight. Microsoft is investing in WPF too. Though it is possible to create out of browser applications with silverlight, they have lot of limitations when compared to a full blown WPF applications.Dont forget that silverlight is just a subset of WPF, for example, silverlight doesnt have ADO.NET, Hardware device access etc. So if your application is merely a business application and you dont have to access hardware devices or database directly then silverlight might be an option, however if your application accessing client machines hardware resources directly then you are better off with WPF.
My suggestion is, If you know before hand that it is going to be a desktop application then go with WPF(or may be even XBAP). In my experience, useful applications grow with time, new features are always requested time to time. If in future,a feature is requested that cannot be accomplished with silverlight and can only be accomplished with WPF, then you will be in a big trouble because you need to rewrite your app in WPF and it will be hard for you to convince your CFO to allocate more fund just to implement one feature. Silverlight is not designed to develop desktop applications, its main goal is multi-platform support.
Silverlight 3 supports Out-of-Browser functionality.
Quote from Wikipedia silverlight page :
Silverlight 3 supports Out-of-Browser experiences, i.e., Silverlight applications can be installed to the system for offline access (provided the application manifest is designed to allow local installation) where they run outside the browser.
Also here is a quick howto
Out of browser applications have the same security restrictions as in browser applications.
With Silverlight 4 you can create full trust applications which have full access to the computer.
More on Network Security Access Restrictions in Silverlight
If you mean Out of Browser apps, certainly. The Seesmic Desktop 2 app is an excellent example of one of these apps, with it's own updating mechanism. Seems a no brainer to use the XAP/MEF plug-in Model and Silverlight in this manner.
Seesmic Desktop 2
We're developing an OOB app along the same lines, one internet download and you're done. You're not going to get exactly the same APIs as you get in WPF, though.
As others have pointed out, Silverlight apps can be installed to run 'out-of-browser', but even with elevated trust they still have significant restrictions on what they can do and certainly don't have "full access to the computer".
Creating an app from scratch, you may want to consider parallel Silverlight & WPF builds. The code can more-or-less be shared by adding the .cs files from one project (e.g. WPF) to the other (Silverlight) using "Add As Link". The XAML files cannot be linked this way and need to be duplicated, but that may not involve much more than copying & pasting, depending on your structure. There're good examples of this on the web.
Developing both types in parallel would likely involve a lot less effort than having to abruptly switch types at some point and discovering incompatibilities/limitations too late.
Silverlight Out of Browser technology and WPF ClickOnce on the surface have similarities. Easy and simple deployment, the ability to specify the level of trust access to the underlying host, etc.
What are the key issues I need to consider when choosing one over the other?
To put a finer point on it, I'll be deploying LOB apps on a corporate network running only windows computers.
The big one is cross platform compatibility. If you need you app to run on a mac as well as windows (not sure if Silverlight is supported in Linux yet) then use Silverligt. If you want to make an assumption that all your users will be in a windows machine then go WPF.
Obviously WPF has a much richer toolkit than silverlight so it may well be that silverlight just isn't an option. If I was just building for windows though I know my job would be easier in WPF.
Given that you are targetting a private infrastructure running Windows, two points worth thinking about
Wpf has a richer control tree, whereas Silverlight is a reduced set for compact size
Wpf requires .Net framework installed locally, whereas Silverlight has its own platform independent browser-based runtime
While your target platform will likely have the latest .Net framework installed, rendering this last point moot, keep in mind any updates to the framework [ie .Net4.0 and any future updates] may require a restart of the machine - which is a major pain point for businesses that demand constant-on stateful desktops [ie anything in finance, like banks and trading].
As with all problems, your requirements, not the technology, should inform your solution. :)
You mentioned trust access to the host which I think rules out Silverlight unless you want to run SL4 (beta).
We recently went through a lot of discussion about file system access. Silverlight 3 runs in a partial trust sandbox more or less. You can't maintain a pointer to files in the files system outside of your application's isolated storage. This was an issue for us as we wanted the user to be able to use the application to reference odds and ends on your file system. That said you can allow the users to load and save files from anywhere on the system but you just get/or push the file stream and (to the best of my knowledge) don't have access to the folder or file path information.
Silverlight 4 (in beta) has support for your application running in full trust mode. I haven't played with this yet however and can't speak to how well it works.
In talking with a lot of people who work with both Silverlight and WPF, even those who are excited about Silverlight and push for it strongly, I hear a lot of the say fairly emphatically that if you are going to be developing exclusively for a full-trust Windows environment, WPF is hands-down the obvious choice.
That's not to say that Silverlight is an inferior product or that there aren't times will Silverlight will be the clear winner. But when you say "I'll be deploying LOB apps on a corporate network running only windows computers," it sounds like WPF is the clear winnder.
You could decide to go down the Silverlight route in anticipation of all of the great new OOB feature os SL4. I've even heard rumors that SL and WPF will eventually merge, so it may not even really matter, right? Well, I think what you'll find if you go with Silverlight is that some of the advanced features that you thought were there weren't there in the way you expected. For example, SL4 will be able to run in "Elevated Trust" (not full trust) and you might find this limiting at a frustrating point in the project where a lot of your code base is already in Silverlight.
Certainly keep your eyes on Silverlight, but for your current business case, WPF will likely be the best fit.