I want to set up a test case of my data tier on Azure. For my scenario this means
putting a SQL Server database into Azure
Storing my custom .dll data access code
Creating a tcp listener to take XML requests, call the custom dll code, and return the resulting XML.
What is a way to accomplish this in the architecture of azure?
My current understanding is that I need to do the following for each step:
Create a VM that hosts an Azure SQL database
Make sure .Net is on the VM and load my .dll
Create a worker role on the VM.
So I'm thinking 1 VM, 1 database, and 1 worker role. I have very little confidence that this covers my needs and I'm not sure what I might be missing.
It shouldn't matter, but our current client is a WPF application.
You have a few options on how to implement this.
For the database you could either start a VM from the Gallery with SQL Server pre-installed on it, and restore your database on it. Or, even better, create a Azure SQL Database, and create your database on that service. The difference: Azure SQL Database is not a VM; it is a service. Chances are, your database should work as-is. But if it doesn't (for some reason), then you can fallback on a VM with SQL Server on it.
Regarding your DLL and website, you could spin up a regular Windows VM, and deploy your DLL and website on it; if you are doing a proof of concept, there may not be a need to have a third machine involved. With that said, if your objective is to also learn about cloud services (web roles for example), then yes, you could also deploy a web role separately, which you would need to configure to connect to your DLL through some sort of web service call. You can deploy your website manually by creating a package from Visual Studio, or push directly from within Visual Studio (both would require you to create a new kind of project - a Web Role project - and add your website to it).
If you deploy 2 VMs (a cloud service and a VM for your DLL), then you will also need to configure a Network (it's a specific service within Azure) so that your website can communicate to your service (where your DLL is installed).
Last but not least, you will need to create a storage account, in which your VM disks will be located. This storage account is also another service that is part of the Azure offering. Your disks will be stored as blobs.
Related
Quick version of the question:
How do I configure a .Net Core windows service to target the correct database in a multi-tenant environment where each tenant has their own database and they all run on the same self-hosted server?
Some background info:
I am working on a new windows service and, since it is completely new, we are going to use .Net Core. I have read this page and it does talk about how to set environment variable in an IIS app, azure, globally, per command window but it does not really mention a windows service, azure devops or how to handle a multi-tenant environment.
The best I can figure is that you are supposed to set the environment variable in the start parameters for the windows service once it is created but that seems very fragile. This becomes more of a problem when you are looking at 25 with a potential of 100 or more (we are a small growing company). The thought of having to go back and set all of these variables manually if we decide to migrate services to another server is not pleasant.
So the longer version of the question is: Am I on the correct track or is there some better way to set this up so that this does not become such a manual process? Perhaps setting a variable when the service is deployed to the server would do the trick? How would I do that with azure devops though?
Edit 1
Here is a representation of the environment we are running these services in.
Databases (separate machine):
Shared1
Db1
Db2
Db3
Machines:
Server1
Windows Services:
Service1
Service2
Service3
The databases are running on the db server. There is one database per service and there is a shared database which stores some common information (don't think this is relevant for the question). There is one server. On that one server there are copies of the code that needs to run as a windows service. The number of copies of the service corresponds to the number of databases. So for the above scenario: Serivce1 connects to Db1, Service2 connects to Db2, Service3 connects to Db3, etc...
Since I only have one machine, if I set an environment variable to something like ASPNETCORE_DB1 then all three services will read that variable and connect to Db1 which is not what needs to happen.
If I set multiple environment variables: ASPNETCORE_Db1, ASPNETCORE_Db2, ASPNETCORE_Db2, how do each of the services know which environment variable to read?
I have a feeling that you are mixing few things here.
If you want to have different settings per environment you just need to use CreateHostBuilder method. You can read about this here. Then you need set ASPNETCORE_ENVIRONMENT environment variable on machine where you host app. In this approach application at runtime selects proper configuration. However, please do not keep sensitive data in your config files. In this approach you have one compiled code for all tenants.
You can pass configuration when you build an app. To do that you should define variable groups (on Azure DevOps) (one per tenat) and flush your secrets to config file. In addition you can use runtime parameters to define target tenant. Still not secure enough as in artifact (compiled code) you can find secrets. In this approach you have one compiled code per tenant.
If you can use Azure KeyVault I would recommend this approch. You can create one KeyVault per tenat and then in CreateHostBuilder load secrets from proper KeyVault (if you name KeyVault with tenant name, it will simplify selecting proper KeyVault). You can read about this here.
According to you question I assumed that your tenat = envrionemnt. If not then you can have one KeyVault per env like Dev, QA and PROD. Then you should name your secrets with following pattern {tenant_name}_{secret_name}. You should load all secrets atarting app and then at runtime (based on tenant id) select proper secret.
I hope it will help you make good decision.
Getting corresponding database connectionstring per environment variable is the better way. Simple steps:
Define the same environment variable with different value (connectionstring) in each environment/machine manually
Get that environment variable value in your windows service app and use that value as database connectionstring if not null, otherwise use the default connectionstring.
Edit:
For multiple windows services on the same machine, I suggest that you could specify connectionstring per to current service name.
How can a Windows Service determine its ServiceName?
I am trying to execute a pre-existing application on Azure Batch.
What I have done so far that I have studied about Azure Batch, since I am a beginner for Azure, and I have created a sample application in C# .NET (Console Application) that interacts with my Azure Batch account and executes an .exe application on Batch pool. My sample application creates a new Job on Azure Batch Pool and manages three different tasks for this Job.
Now I look forward to my pre-existing application to execute it on Azure Batch. The problem is my application uses MS SqlServer as database server. I'm not sure how to deploy this app on Azure Batch. As we know, In Azure Batch, we have to upload our data files and application code on Azure Storage in case to execute on Batch Pool Nodes so here how would I suppose to upload my whole existing database.
I would appreciate the precious suggestions for looking forward.
There are a few paths forward:
Create a custom image that contains your application (MS SqlServer) with all of the data preloaded. You can use this custom image as the operating system to use for the compute node.
Package your application (and even the data) as an Application Package coupled with a start task to install, if required. If you don't want to package the data as an application package, you can use a resource file for this instead. This does not require a custom image.
Use a start task as you would like option #2, but use Resource Files to download your application. This might be a simpler option if you do not need to have Batch manage your applications. This does not require a custom image.
Package your application and data as a Docker Windows Server Container. As of 2017-10-19, Batch provides "native" Docker container support with the SKU 2016-Datacenter-with-Containers. You need to specify a ContainerConfiguration on the pool and tasks' should specify TaskContainerSettings. Note that this documentation is for REST, the .NET documentation is forthcoming.
The custom image path may be the path of least resistance, but may require more upkeep in the future depending upon your scenario requirements for software freshness and data needs.
I'm working on a project and I need to connect to MS Access Database. The problem is that I'm using a pretty new platform , I'm using Visual Studio 2015 Xamarin and I'm developing to android with c# (thought this platform).
I already have a project with this Database using aspx and i need to connect the android application to this Database .
I could not find any answer for it , probably cause it's new .
Thanks for helping.
The problem is not related only to Xamarin or MS Access.
Everytime you want to use the same database in different applications (in your case a website and mobile apps), it is better to create a new layer (WCF Service or REST API) in order to access the same database on the server. This is more flexible and would be the right thing in your case.
Without moving the architecture to the next Level, you will always have such problems when mixing old and new technologies together.
If you just want to finish this quickly for school and use the database only on the device, then there is no way to use the MS Access database with xamarin. I recommend using SQL lite for this and there are lots of examples for that:
https://developer.xamarin.com/recipes/android/data/databases/sqlite/
It not clear if the database is to run “local” on the android, or you just wishing to connect to some web service that holds the database?
If you needing a local database to run 100% stand-alone on the Android device, then Access is not supported. Your best bet for a local database would thus be SQLite.
Perhaps you don’t need nor want a local data store. In this case if the Access database is on the server, then you would be forced to write some kind of web service to “interact” with your Android software and the web server (this would not be a "general" interface to the database, but a set of web services that you expose on the web site - this assumes you thus have control and are able to write software and implement a web service on the web site. So in this case some kind of “direct” connection to the Access database is not possible.
You could again certainly DIRECTLY connect to a server based database like SQL server – but this would assume the web hosting allows external ODBC connections to the database (often they don’t allow this, but some do).
So not clear is if you need a local database running on the Android that can THEN connect to some web or server based system, or you simply want the android to connect via the internet to some database hosted on some server and the Android device does not have a local database at all.
Regardless of the location of MSAccess, you cannot "connect" to a non server database like Access. So the question remains as to "where" you want this database to be used, and ALSO if you need a local data store on the Android device or not.
I'm pretty new in developing pc and mobile applications that need to work with the same database.
Maybe this isn't really a question but I would be happy to get some advice from you.
I have now a vs project written in C# with a Service-Based Database. I want to create a mobile app (can be only for android) and I want both the apps to use the same database.
What options do I have? Windows Azure isn't free and I can't spend any money on this so even a small trial (limitless) will work here.
I was thinking using Parse..
What do you recommend?
If I understand correctly I would suggest you create some backend service - web service or web api - that both application use which in turn uses the database.
This will allow you to re-use business logic across both applications, abstract the database away so that you can make database and logic changes without having to redeploy the applications and avoid the requirement to deploy database credentials with your applications (the backend service should employ some form of authentication)
A free-tier Azure mobile services can really help with the mobile device end but not necessarily on the PC (unless windows store app), but a free-tier Azure websites instance will happily host either web service or web api
I wrote an application in c# & SQLite for storing data of all employees in a company which has around 500 employees. I want to put the database & the application in a file server/shared folder (MS server). Then all employees will have a shortcut of the application in their desktops. I want to make some input fields (text box) enabled/disabled based on the permission of the user runs the application. Whats the best practice for doing that?
I want the user can read/write in the database through my application only (the application is located in the same database folder). I don't want the user to reach the database without my application. How to do that?
I don't want the user to reach the database without my application
If your application will directly access the SQLite database via a Windows file share, this is impossible. Sure, you can make it inconvenient, but it's not really possible.
The only way to achieve this really is by introducing some middleware.
This would typically be a service (WCF perhaps) that listens for connections from your client application, authenticates them, and manages all access to the underlying database. The database would be stored in a location that is visible to the server only, and not visible through a Windows share to your users.
Also, SQLite isn't exactly a great choice for a multi-user system. You can kill two birds with one stone here - switch to a DBMS (MS SQL Server Express is free, also MySQL, PostgreSQL are common free choices) that accepts client connections over a network, and build your application to connect directly to the database server (using integrated Windows authentication may also be possible like this, so you can avoid an explicit logon). In a simple scenario this may be adequate and avoid you needing to build an explicit service layer.
In a more complex scenario, it can still make sense to have a middleware layer between the application and the database - this way, you can change the database design without changing the application design and deploying to all of your client machines - instead, just change the middleware layer in one place and your application won't know the difference.
If you don't want the users to reach your database you should create a client server architecture.
You can run your service on the same machine as the file server (running as a Windows Service) and use WCF for communication between your server and your client. You access your database from your server and let your server authenticate your users and validate that they have access to the application.
You can cheat and try to "hide" database credentials inside your client application, but that is security by obscurity and any one with some programming skills or similar can find out the credentials to the database and connect directly to the database.