Can we implement a enterprise wide intranet application completely with WinForms instead of Browser based Web apps?
What are pros and cons and which is preferred over other?
Some stuff on my mind:
WinForms Pros
Richer user experience
More responsive
Usually easier to write interactive processes
Web App Pros
Centralized maintenance (easy to update, ...)
Centralized data access security
Easier to access over the Internet and on the go
Does not rely on anything except a browser on the client (so the client platform doesn't matter)
We developed a lot of winforms apps at the place I used to work. ClickOnce made things a lot easier in the case of deployment.
Related
We need to create an application that can be used via the browser but that can also be used while offline.
The browser Version will be used by our customer to do calculations. Each customer needs to log into the application with a username and Password.
The offline version will be used by our own employees. They need to be able to use this Version while not connected to a Network.
The data that is needed for the application will be stored in XML files.
We are mainly programming with C# and the .NET-Framework. We thought about using WPF for the client version.
I have read that you can use Silverlight or XBAP to create a browser Version of the WPF application. AFAIK Silverlight is a dying Technology. How about XBAP? Would you still invest into this Technology?
The other solution would be to create two front end applications: The WPF application as an offline application and a web application (e.g. ASP.NET MVC) as a web application. Thought, this would mean that we would have to create two frontends (more work).
Is there another alternative?
Would it be better to create an HTML/JavaScript application (e.g. with AngularJ or something similar)?
As a former Silverlight Developer I can only recommend not to use Silverlight for new application development. Microsoft has suspended the further development of Silverlight and you will not get any new features (only security fixes). I really liked the technology and the similarity to WPF but for me it is deprecated.
Even some Browsers (like Chrome) do not support Silverlight anymore and you need a workaround to get it running (See also Chrome doesn't support silverlight anymore? How to solve this?)
Develop a Backendsystem that provides a REST-API (using ASP.NET WebApi as an example) for your clients and develop a Browser client application using modern HTML/CSS/JavaScript Frameworks. If needed/required a desktop application using WPF that consumes the REST-API.
Silverlight may be dying, but that does not mean you should avoid using it. Silverlight is still a viable technology that you can use, however browser trends seem to be phasing out Silverlight support. As far as I know, Microsoft Edge browser is no longer supporting Silverlight, so you will need to use Internet Explorer. This isn't the end of the world, but it's something to think about.
As for WPF, this too is being replaced by Windows Universal Apps, albeit slowly. However this isn't too much of an issue as the skills you have learnt in WPF are easily transferrable. WPF itself is not receiving as many new features as it used to, you could say it's finished.
It isn't always easy to keep up with the latest trends, and there will always be something cool and hip just around the corner, however one thing is for sure, the .NET Platform, including the new refactored Universal App APIs are here to stay, and won't die any time soon.
The current trend sees Web Technologies, such as ASP.NET playing a much bigger role than traditional desktop/tablet/phone applications. I would say that developing for a web browser is certainly a popular choice.
That being said, Windows Universal Apps is also a good choice, in fact, any technology that makes use of the .NET Framework is ideal.
As for my recommendation, I would suggest looking into an ASP.NET web application or Web API to which a desktop application, such as WPF (still a viable technology for enterprise applications) or Universal Windows App can hook into. An ideal scenario would be that both applications share the same back-end code, which is certainly possible as they both use the .NET Framework.
For your requirements, it may even be possible to avoid having to create a desktop application altogether, a web application can be hosted on a machine on the local network and clients can still use the web app. This is assuming that these clients don't have internet access of course.
TL;DR: .NET is legit, use ASP.NET.
I am reading about out of browser silverlight applications and cannot think of many use cases for it. One only scenario i can think of is where your application need ability to work offline and when its online then it can synchronize with the server ( or something). But in that case I can simply have a WPF ( or old style Winform) application that is communicating with server. Can anyone help me understanding better uses case for these out of browser applications.
There are some good answers on SO that should give you some background on Silverlight OOB vs. WCF:
Silverlight OOB vs WPF ClickOnce
What are the advantages of silverlight out of browser over wpf or vice versa?
I will add that as a corporate developer Silverlight has its benefits over WPF or WinForms in that there is no need to install the full .NET Framework to run the applications. OOB gives a more desktop like feel w/ Start Menu icons and easy access w/out the need of visiting a URL to run the application. There are a few things that you can do in elevated trust in OOB that you can't do in the browser (though that is changing w/ full trust rights both in-browser and OOB in SL5).
Here's some of the details on the features you get access to w/ elevated trust:
http://msdn.microsoft.com/en-us/library/ee721083(VS.95).aspx
It really comes down to your usage scenarios, ease of framework deployments and the environment you are developing for. Each set of tools has its benefits and drawbacks.
I'm in the early planning stages of an internal application and I'm considering ASP.NET MVC and Silverlight 4 as my possible platforms.
The Environment
We're a Microsoft shop and we're in the process of migrating desktops to Win7 (from XP) and servers to W2k8, I'll be able to get Silverlight 4 installed as part of our baseline Win7 build
The Application
Provide a dashboard to monitor system status
Monitoring third party connections
Monitoring database tables for particular events
Monitoring SQL Server Log Shipping
...
Provide portal like access to system tasks to end users
Bulk updates to databse rows
Running SSRS Reports
Re-running automated tasks that have failed
...
The Team
We're a small team of 2 and neither of us have production exeprience in Silverlight or ASP.NET MVC so we'll be learning whichever we go for.
What would you pick and why?
The answer really depends on your experience. If you are an experienced web developer and have a lot of practice with ASP.NET then use that for sure. If your background is WPF and WinForms then use Silverlight.
My experience is that the ramp up time to use Silverlight for an ASP.NET developer is significantly longer than it is for a straight .NET application developer. The ASP.NET developer has to unlearn a great deal before they begin because the development paradigm for Silverlight is more akin to app development.
The other alternative is to use both. ASP.NET for the navigation, authentication, general layout and Silverlight for the data realisation (graphs etc).
I would pick ASP.NET MVC. I have experience in both Silverlight and ASP.NET MVC and Silverlight undoubtedly has a steeper learning curve. While it will definitely enable you to develop rich user interfaces (it enables amazing composition) it may be overkill for an internal application.
ASP.NET MVC on the other hand will enable you to do what you are aiming to achieve but I believe (due to the learning curve) you'll be able to do so MUCH more quickly. It is also much easier in my experience to enable dependency injection and write unit tests for ASP.NET MVC than it is for silverlight which may or may not be a consideration..
Silverlight. I think ASP.NET MVC more for public websites, whereas internal applications - Webforms or Silverlight in your case.
Silverlight - Desktop > Web for applications (not for simple data presentations though) whenever possible. The bad news is that desktop is not always possible. The good news is that it is possible for you. You can even use the out of browser features which is even cooler.
Use Silverlight with the MVVM pattern.
We are planning to build a new integration component that can provide us access to user's machine installed apps from our web site.
The first word that came to me was ActiveX, but our expertise with the technology was not the best in the past.
Thinkink a lit bit more, the work Silverlight also came to my head, but the full trust thing was one of the few things I remembered reading about the technology..
The question is: is there a way that Silverlight (2, 3, 4, whatever) can run as a full trusted application from within the browser?
Links are appreciated.
Filipe
Unfortunately, no. Full trust is a feature of Silverlight 4, currently in beta, and is restricted to out-of-browser applications.
Additionally, full trust SL4 applications do not have unrestricted access to the system (particularly file system), though this may change before before release (if I have anything to do with it).
Edit: If you are considering ActiveX (which is Windows/IE only), you might want to have a look at WPF, since it can run full trust from the browser (if it's in a trusted zone).
No, like Richard said, this is not at all possible inside the browser, even in SL4. There is a sandbox, and you live in it. You can talk to web services, other Silverlight applications or the browser.
By talking to the browser, I mean you can talk to the DOM and the Javascript engine. We needed to launch a Windows application and communicate to it via Silverlight. We accomplished this by putting a small ActiveX control in the web page. It is responsible for launching the WinForms application and handling inter-process communication to it.
This method has many drawbacks: It can only work in IE, and it only works in Windows. You might also run into permissions issues. The ActiveX component needs to be installed along with the desktop application, or as an additional download. The deployment story there is pretty awful, if you ask me.
In our case, the analysts were willing to deal with the restrictions for the re-usability of an existing application, and we consider it to be an optional feature.
Does it have to be a web application? sounds like you want a desktop app. It can be easiliy distributed with one Click deployment. Will work on windows only but since you were considering ActiveX sounds like that's what you need.
Well - if you're hosting the silverlight control from an ASP.NET application - Believe you have access to
Request.ServerVariables["AUTH_USER"];
...and you can pass that on to your control as a parameter.
D
I want to know what is the main technical difference between Web (ASP, PHP, Ruby, etc.),
Application (C, C++, .NET, Java), and Mobile (J2ME, Objective C) programming, and which is the hardest.
If someone learns one of these, can he easily switch over to one of the others?
First, from a technical perspective you should be asking the difference between Web Applications and Client Applications. Within each category, you can ask about the difference between standard Web Applications and Mobile Web Apps and standard Client Apps and Mobile Client Apps.
The difference between web and client applications is that web applications lack state: every page request is completely de-linked from every other page request. It is only through various technical work-arounds that web applications manage to maintain the illusion that a web app user is running a coherent application as they navigate from page to page. In ASP.NET, for example, the ASP.NET ISAPI DLL manages a "Session" object that pulls a session cookie from the user's page request and then provides uses it to identify the Session data appropriate for the handling of the request.
In a client application, by contrast, every aspect of the application is targeted at a single user and the "state" of the application is a given as you navigate from dialog to dialog. In addition, the tight integration of the application with the user's computer permits the use of on-board resources (memory, disk). In a web app, by contrast, there is little or no access to these resources except as mediated by the browser (which is a client application, not a web app).
Mobile web applications are, essentially, just web applications with two caveats: the screen size is considerably smaller and the browser capabilities are generally less robust. Thus, you'd write a mobile web app in pretty much the same way as a standard web app but you can not count on some of the capabilities that you usually have with a full-blown browser. This last constraint, by the way, is rapidly going away as mobile devices become more powerful.
Mobile client applications require a development environment, deployment strategy, etc. that is specific to the mobile device. The tools and techniques used in standard client application development don't map particularly well to the Mobile client. Instead, you'll need to learn new tools, controls and techniques. The only real exception to this rule are the tools available through .NET. Microsoft has attempted to provide as much commonality as possible although, even here, you'll find that you have a different mind set and different constraints than when developing a WinForms application.
Hope this helps!
It's the context in which these applications run.
Web Apps run on a server, intended to serve a large number of clients using a web browser. Even though the web-servers themselves run on some OS, the web applications that run on them are not tightly coupled to that OS.
Mobile and Desktop applications are usually more tightly coupled to the OS on which they run.
Mobile applications can be written identically to desktop applications, roughly as windows apps, console apps and browser apps (because most mobile platforms support a browser). But the mobile versions of most tools are more constrained; and there's usually communications involved, which often makes development more challenging trying to keep various kinds of State straight. And you usually have to be more sensitive to subtleties in the UI code.
There's really no particular dichotomy between Mobile apps and Web apps. The concepts aren't particularly orthogonal.
If you look at a programming framework like .NET, you'll easily be able to switch between Web (ASP.NET and Silverlight), Mobile (.NET mobile) and Desktop (.NET and WPF) as the languages are all based on the same core framework. You can write .NET in different languages, the most common of these are VB.NET and C#.
Personally I'd recommend C# if you are learning. You'll find more examples on the internet, and it will also be more similiar to languages that you may want to learn in the furture (JavaScript, Java etc)