I have written and deployed an ASP.NET application that is pretty complex. It uses XSL transformations to create web forms for a large variety of data objects. The data comes from the database as XML via a web service.
Now, I need to create a Windows desktop application that will provide a small subset of the web applications functionality to a user who may not have access to the web (working in remote areas). I will provide the data syncing using the MS Sync Framework. And I will have the desktop use a local data store.
I would like to use the same xslt files in the desktop app that I use in the web app for the form creation so that, if changes are made, the desktop app can update itself when it connects and syncs its data.
But, I am wondering how to replicate the asp.net codebehind logic of my web app in the windows forms. If I use a browser control to render the XSLTransformation result, then how could I handle click events, etc, in the form? Also, can I launch other windows as "dialog boxes" from my windows forms (I do this in my web app using RadControls functionality)?
Thanks for any advice you can give.
Related
We have a regular .Net4 desktop application built using WPF that exposes a handful of methods via WCF as Net.tcp and also WSHTTP as a rest interface for some simple remote control and remote querying. This is so we can provide some easy 'dashboards' that keep track of what each of the applications is doing around an organisation. We have used MVVM patterns wherever possible with future expansion in mind.
We now need to build a web application for users to do some remote work. Most of this work will be done by the web interface itself directly accessing the SQL database and other resources and rendering HTML back to the end user.
We also want the users of this web application to be able view these dashboards for certain specified desktops, at which point we need to then have the Web application query the desktop applications for the answers.
In due course it's likely that we will expand this further to expose REST or SignalR based or similar to support a Xamarin based set of apps.
My current theory is that we will build this web application using ASP.Net and host on IIS and whenever the user needs to access a resource that requires connecting to the desktops we spin up a WCF connection to the REST services running on it, send the query, process the result and return it onwards to the user.
Is this the best way to go about it, or is there some sort of native web service "proxy" that we can utilise to transparently forward the request from the website user onto the desktop?
Any and all advice would be greatly appreciated!
My aim is to develop a web app and a mobile app that share data from the same database.
What is the best way to achieve this (using azure)?
I think I should:
Create a Web App from Azure Portal with a SQL Database
Create a Mobile App from Azure Portal with an existing Database (the one I created before)
Then I'll develop my ASP.net MVC project, using Entity Framework to create the db Schema and I'll publish it in Azure.
Finally I'll develope my mobile app (in this case I would like to use Xamarin) and I'll access to the database (created before) using the code for Easy Tables.
Is it right? Or I'm thinking wrong and this isn't the best architecture to share the same database between a web app and a mobile app using Azure?
This should be fine. Keep in mind that the Azure Mobile Apps server will automatically add some system columns to your database tables (createdAt, updatedAt, deleted and version). Also, a limitation of Mobile Apps is that the primary key name must be called id.
If you want to develop the web site and mobile app share the same database, it is a good choice.
Azure Mobile Apps is a plain old ASP.NET application or Node.js application. Easy Tables is simply a projection of data from the Node.js version. If you are using ASP.NET, then you don't get Easy Tables.
That being said, it is relatively easy to add Azure Mobile Apps SDK to an EXISTING web app.
1) Copy the code from App_Start\Startup.MobileApp.cs and Startup.cs from a sample app to your ASP.NET app
2) Ensure all your models inherit from EntityData so that they are "mobile ready". If your models already have an auto-incrementing Id column, then see https://shellmonger.com/2016/05/11/30-days-of-zumo-v2-azure-mobile-apps-day-19-asp-net-table-controllers/ for a workaround
3) Scaffold Azure Mobile Apps Table Controllers for your mobile database table projections.
You can use the same models across both MVC controllers and Mobile controllers. If your app uses AJAX calls for getting data, you can replace those AJAX calls with the JavaScript SDK for Azure Mobile Apps so you don't have to duplicate things.
The main place you are going to have to work on is integration of auth. Most MVC applications use an Identity database because they have grown it from one of the existing MVC templates. You are going to need to implement a custom mobile auth mechanism to re-use the database. You can find information about this on the azure.com HOWTO documentation.
I've been studying Xamarin.Forms with goal of building cross-platform mobile app in VisualStudio2015. I've got a perfectly acceptable public facing web site but native app(s) are what the boss thinks we need.
The current web app hosted on IIS 7.5 uses a separate project(DLL) for database access to an on-premises SQL Server 2008 instance. This VStudio project exposes domain objects to the calling ASP.NET webforms by executing various stored procedures using System.Data.SqlClient.
I know building the mobile native app itself with Xamarin.Forms is one part of the challenge but I am asking here for clarification about how to approach the database requirements:
Do I need to create some sort of web service that provides the same CRUD functions required by my current web site?
Xamarin documentation lists several options for consuming web services and the more I search and read about data access I conclude that a callable web service of some type is going to be required for my eventual native mobile app.
Is this assumption correct?
Yes. You generally want a webservice layer brokering requests between your mobile app (or any remote client) and your DB server. If you already have all your crud operations in a separate library that is utilized by your website, then a webservice would just be another set of endpoints that rely on the same CRUD library.
Providing web features through a custom HttpHandler such as in Elmah is extremely handy for ASP.NET Web Applications, because the handler can be embedded into any ASP.NET web app. It perfectly fits as a simple way to extend an existing web app.
Now, developing any significant set of features through a custom handler is a very tedious process. I am wondering if it is possible to directly embed an ASP.NET Application into another one through a custom handler (as opposed to cut and pasting the whole app in a sub directory).
Here is a small list of embedded web app that would be fit for such a purpose:
Health monitoring console.
Provisioning console (for cloud web app with auto-scaling).
App settings management console (considering a scheme IoC-settings-stored-in-DB).
Each one of those web parts could be provided as an HttpHandler; but again implementation is really tedious.
Does anyone know how to do that or how to achieve an equivalent behavior?
Do you usually put your features in a business logic DLL and just reference it from as many applications as need the business logic? What are you trying to reuse that this wouldn't work for?
I have a .NET 2.0 WinForms application that was developed using the Composite Application Block and Smart Client Software Factory.
I'm considering the development of a module that would contain a browser control that would access the ASP.NET website using credentials established when the user logged into the WinForms client.
My goal is to use this strategy to transition all of the modules that are currently in the client to ASP.NET and retire the 'smart' client. Security for the WinForms client is currently implemented using the ASP.NET Membership functionality.
Is this possible? Sensible?
Yes, you can. Make a SmartPart that hosts the WebBrowser control, add some buttons for forward and backward navigation, and a url textbox; then point the WebBrowser control at your web application's URL.
It is sensible. We used CAB/SCSF to create an application we called "The Integrated Desktop". This application serves as the platform for all internal apps for the company; everything is integrated into this one desktop application. We added a foundational module, basically a beefy version of what I described in the above paragraph, to facilitate web browsing since a few pre-existing apps were web-based and our users wanted access to those at the same place they were doing all their other work. One cool thing was the use of the WebBrowser's ObjectForScripting property that allowed for somewhat seamless integration between the desktop app and the web app being hosted inside.
What are your requirements?
You would choose a web app over a smart client mainly
if you have to reach people that
are not on the Windows platform or
you have a need for a
zero-install app
By having your app users having to access the web app via the smart client (browser-control) you would be missing (1) and (2). In my opinion it would defeat its purpose.