We are developing a desktop Windows 8 application, that work with WCF-service. We want enable work with Azure WCF-service and with WCF-service in local network(choosingly). Application will be publish in Windows Store.
What the best practise deploy WCF-service on local server of company?
I understand what you want. Let's pretend the Azure part is not an option. How can a Windows Store App use a local service (WCF or not)? That's the fundamental question.
Here's the answer(s):
First, a Windows Store App cannot access intranet services unless it has private network access declared in its manifest. It looks like this:
Second, in order to use private networks in your manifest and get accepted into the Windows Store, you must be a company publisher and not an individual. More on this is discussed in this SO question: Which features are allowed for company store accounts and not individual?
Third, a local service cannot be mistakenly thought of as localhost. To this end, localhost is not available to Windows Store Apps, unless they are side-loaded (which means they are manually installed and not delivered through the Windows Store at all). To access localhost, you can enable loopback, but, as I stated, this disqualifies you from the Windows Store. There's more on this here: How does Windows 8 Loop Back work?
Forth, because you are talking about a service, you might want to authenticate the user. This is accomplished using enterprise authentication (just like in number 1) only a few checkboxes higher. And it has the same restrictions as private networks.
Fifth, you are not asking this, but to be clear, local access does not mean you can speak to a local SQL server. The reason for this is because the SQL namespace is not part of WinRT or .Net for WinRT. Windows Store Apps are intended to be service-based apps.
And, that's about it. I think you are good if you follow that.
It doesn't sound like you are talking about a pure enterprise-play, but it might be interesting to you to read through some of the strategies for enterprise developers: http://blog.jerrynixon.com/2012/08/windows-8-apps-whats-enterprise-to-do.html
As for deploying WCF, there's nothing special just because a Windows Store App is accessing it. So for deployment, just use vanilla techniques you are already using. :) That's it.
Best of luck!
Related
I'm new to web development and just built my first website with .Net Core. It's primarily HTML, CSS, and JavaScript with a little C# for a contact form.
Without recommending any service providers (question will be taken down), how do I go about deploying the website? The more details the better as I have no idea what I'm doing haha.
Edit: I am definitely going to go with a service provider, however the business I am building the website for doesn't have a large budget so I want to find the best provider at the lowest cost.
Daniel,
As you suspect, this is a bit of a loaded question as there are so many approaches. One approach is to use App Services within Microsoft Azure. You can create a free trial Azure account to start that includes a 200.00 credit, which is more than enough to do all of this for free. Then, using the Azure Management Portal, create an App Service (also free) on an App Service Plan in a region that makes sense for you (i.e. US West). Once you do that, you can download what is called a Publish Profile from within the App Service's Management Portal in Azure.
If you're using Visual Studio, for example, you can then right click your project and "Publish" it (deploy to the cloud, or the App Service you just created). One option in that process is to import an Azure Publish Profile, which you can do with the one you just downloaded. This makes it really simple. The Publish Profile is really just connection information to your Azure App Service (open it in Notepad to see). It will chug for a bit and then publish and load the app for you. You can also get to the hosted version of your app by clicking the Url of the app in the App Service management portal on the main page.
This may be oversimplifying what you need to do, but this is a valid direction to take. AWS and others have similar approaches.
Again, tons of ways to do this, but this is a free approach. :-) I don't consider Azure a Service Provider in the sense that you asked us not to. Instead, I wanted to outline one turn-key approach with specific details on how to get there.
You can find specific steps in a lot of places, such as this link:
https://www.geeksforgeeks.org/deploying-your-web-app-using-azure-app-service/
DanielG's answer is useful, but you mentioned you don't want use any services from service provider.
Usually, there are only three ways to deploy the program,
first one is the app service provided by the service provider mentioned by DanielG,
**Benefits of using service provider products:**
1. Very friendly to newbies, follow the documentation to deploy the application in a few minutes.
2. It offers a very stable, scalable service that monitors the health of our website.
3. We can get their technical support.
**Shortcoming**
It is a paid service, and although Azure's service has a free quota, it will run out.
**Suggestion**
It is recommended that websites that are officially launched use the services of service providers.
second one is to use fixed IP for access (it seems that fixed iPv4 IP is not provided in network operations),
**Benefits of using fixed IP:**
If there is a fixed IP address, or if the carrier supports iPv6, we can deploy our website, and the public network can access it. And if you have domain, it also can support https.
**Shortcoming**
1. There are cybersecurity risks and are vulnerable to attack.
2. Without perfect website health monitoring, all problems need to be checked by yourself, and it is very troublesome to achieve elastic expansion.
**Suggestion**
It is generally not recommended because there is no fixed IP under normal circumstances. Broadband operators used to offer it, but now it doesn't.
If you are interested, you can try ipv6 to test.
the last one is to use tools such as ngrok or frp for intranet penetration.
**Benefits of using intranet penetration:**
Free intranet penetration services such as ngrok, the URL generated by each run is not fixed, and there are some limitations, such as a new URL will be generated after a certain period of time, which is enough for testing.
Of course you can purchase the service of this tool, which provides fixed URLs and supports https.
**Shortcoming (same as the second one)**
**Suggestion**
The functional implementation is the same as the second suggestion, and the physical devices used by the website are all their own. The intranet penetration tool (ngrok, or frp) solves the problem of not having a fixed IP, providing a URL that you can access.
There are few users and the demand for web services is not high, so it is recommended that individual users or small business users use ngrok and frp in this scenario. Generally suitable for OA use in small businesses.
I realize that we cannot directly access SQL Server database from a UWP app, and have to use a WCF service as a mediator for this. (Which is totally stupid, since even competitors like MySQL provides API for Microsoft's runtime, while Microsoft's own RDBMS does not!)
I don't have any experience with WCF, but after going through some tutorials, I believe I can make a WCF service to communicate with my SQL Server (although I do not like making my simple application use a 3-tier architecture, which shouldn't be imposed on me). Anyways, I do not want to host this WCF service on my website, since I'm making this only for this UWP app. Is there a way I can bundle/pack this WCF service along with UWP app itself, such that service runs on client machine only when thhe start my app, and stops later when app is closed/suspended/minized.
The UWP app I'm developing, also have a WPF version and a web version (in ASP.NET), all of which were connected to MySQL database till now, and it worked flawless. Recently I decided to shift to SQL Server since I'm using Microsoft technologies for all my softwares and thought SQL Server will have better integration and support. But now I find it rather opposite, and thinking to switch back to MySQL database.
You can not bundle a WCF service (or REST api) with your Universal Windows app. UWP apps run in a sandbox environment on a different .NET runtime than your WCF service. You could run the WCF service in IIS, or even better create a self-hosted ASP.NET WebAPI project (so no need for IIS) to access your database. But this service will have to be installed separately from the app.
Note that because UWP apps run in a sandbox, some in-app databases like SQLite are inside this sandbox and can not be accessed by your other apps (WPF, website) by default (there are some hacks to bypass this).
So I think your best bet is to stick with MySQL and use the MySQL connector.
We are currently planning to develop a suite of Windows Store Apps. They are independent and fully work alone, but they are related and act in concert. If a user has several of them, they should share some of their settings (and data), so that the user does not have to manually change these settings in every single one of them.
Is such a scenario even intented?
And how to implement it?
Registry: Does not work. Apps cannot access the registry.
ApplicationData (LocalFolder, LocalSettings etc.): Does not work. Apps cannot access the data of other apps.
Cloud services: Kind of works, but only when the machine is online. Our apps should work offline, too. And we would need to create/rent such a cloud service, which would cause additional costs.
KnownFolder.DocumentsLibrary: This –currently– looks like the only solution to me. The apps are already saving and sharing data there, so let's just save our settings there, too. But the name of the shared folder is one of the settings! And Windows Store Apps cannot create hidden files, so the user can see the settings file. This makes this solution a bit... "rough".
Any other ideas or additional information I have missed?
If you want them to sync with each other instantly, even when the device is offline, then that's your only option. Windows 8 Apps are not intended to share settings.
So much want of sharing.
Roaming API will only share with the SAME app, the SAME user, ANY W8 device.
SkyDrive will only share across ANY app, the SAME user, ANY device.
Using Azure (or any web service) will share across ANY app, ANY user, ANY device.
Don't do this
Don't use the register, the API is not supported
Don't use the file system, the boundaries cause your app to be brittle
Don't use ApplicationData.AnyFolder, this is restricted to a single app GUID
You had might as well get "instant" out of your language, man. That just doesn't happen. But you can have fast (let's call it near instant); you can use Sockets or SignalR to connect your client to some service out there with nearly instant responses. A less sophisticated approach would be to poll from your client, too. It has served developers for decades.
I have the following scenario:
We develop a silverlight 4 app for our customers, that will be used as an out-of-browser app. The app is working offline, i.e. app and database are on the users local machine. The app is using WCF-RIA-services to connect to the local database. The database will be an SQL Server Express, SQL Server CE or MySQL. We are using MVVMLight and MEF.
An external webserver is only used for updating the app from time to time or adding new modules to the app. To achieve this we do something similar as shown in Jeremy Likness blog (http://www.wintellect.com/CS/blogs/jlikness/archive/2010/05/25/silverlight-out-of-browser-dynamic-modules-in-offline-mode.aspx )
The reasons why we are doing such a scenario are complex. But to keep a long story short it is mainly for compatibility reasons for a later online version and we don't want to use WPF. So we need to get this working with Silverlight and WCF-RIA services.
Ok, that's the scenario and here's the question:
Do we need a local webserver in this scenario? The app is programmatically installed as out-of-browser, the database is local and connected via WCF-RIA.
If yes, which webserver would be sufficient? It should be installed and configured via an initial setup that is executed by the customer. The customer should not have to do anything with configuring the webserver.
Any other ideas or comments on this scenario? Any other possible solutions for this?
Thanks for your help
Dirk
silverlight wasn't meant to be used this way I think. So it would be like when you are developing app in visual studio and use Cassini to see result - everything runs locally - but you still need a web server. Maybe more info here - http://www.infoq.com/news/2010/06/WPF-vs-Silverlight
I´m not able to provide with a full answer to your problem, as we are currently facing the same problem. (WPF not being cross-platform, Very specific hardware on some clients)
But I may share some of our thoughts on our type of Thick-Silverlight-Client:
To keep deployment etc. simple we use a self-hosting process (installed as background process)
We may not use RIA as the background process has to run using Mono VM (but for MS-only solution see Can WCF RIA Services be self hosted? )
Architectural thoughts on standalone "Clients":
Depending on your requirements implementing a server for each client communicating with the "main"-server by messages (NServiceBus) may be overkill. But if you want to use a client database if offline and silverlight for ui you should consider using an event-driven-architecture.
There is a slideshow on combining "Event-Driven-Architecture" & "CQRS" with Silverlight. But i would not use it as a blueprint more like an inspiration.
http://www.slideshare.net/dennisdoomen/cqrs-and-event-sourcing-an-alternative-architecture-for-ddd
I am in the process of integrating our custom web app with QuickBooks Enterprise 9. My thought is that I could use QuickBooks as my "database" of sorts. When a person creates an invoice, the invoice is actually stored only in QuickBooks. When a person views a list of invoices, they are actually viewing a list of QuickBooks invoices. I want to make sure the data is stored in only one location.
I realize that I could use the QB Web Connector, but the problem with that is I wouldn't have control over when the requests to QB actually get processed (That job is up to the Web Connector).
So I have my web UI to act as the QuickBooks "face," but I don't have any good way to get to and from the QuickBooks file located on an internal server. What I was thinking was that I could create a WCF web service and install it on the QuickBooks server. The web service could then be my integration point. My custom web app could then consume the web service and, viola, I have access to my QuickBooks files.
My question is this: Can a WCF app connect and run QuickBooks? If not, could i create a Windows service to act as my point of integration? If so, can my custom web app "consume" a windows service?
I'll start by warning you that QuickBooks probably isn't your best choice for a reliable back-end database accessible from a remote website. In fact... it's probably a really, really bad choice.
You should have your own application database, and then if you need to also exchange data with QuickBooks, do that outside of the normal lifecycle of your app, as a separate sync process.
QuickBooks generally isn't reliable enough for always-online type of applications due to a number of reasons:
Flaky SDK connections
Updates and single-user mode will
lock you out of accessing QuickBooks
Difficulty in establishing SDK connections from non-GUI processes (Windows Services and IIS processes)
With that said...
Yes, you could create a WCF web service, host it on the QuickBooks machine, and make your WCF web service relay messages to/from QuickBooks.
Yes, you could also create a Windows Service that does the same sort of thing.
Do NOT implement it as a Windows service, and do NOT implement it within IIS - instead implement it as a GUI app that runs alongside QuickBooks.
If you try to implement things as a Windows service or within IIS, the QuickBooks SDK requires you have a GUI available (it users a GUI COM message pump for events dispatching or something like that...) to process requests, so you'll probably need to use something like QBXMLRP2e.exe to straddle the process boundary between QuickBooks and your non-GUI Windows service/IIS. My experience has been that it's a gigantic pain in the butt, and requires mucking with DCOM permissions as well.
I have an example and some documentation on my QuickBooks integration wiki.
The IDN Forums are a good place to ask questions.
My recommendation to you would be to either:
Use the Web Connector and QuickBooks
and give up hope of keeping all of your data in one place. Cache the data in a real database, and update it by querying QuickBooks periodically. I'm almost done building a solution to do exactly this right now, and it works fantastic.
OR
Use a different account system. NetSuite is pretty nice. I'm not sure what else is out there, but if I were you I'd look for something SQL-based or with a strong SOAP/REST API.