I have a WPF application that should have been designed as a service since I realized that when the user logs out, the application closes. The WPF side has just a few settings such as DB name / password, OAuth token that is needed by the service. What is the best way to transfer that info from the WPF view to the Windows service? I had thought I would use registry settings, but it looked like that is getting phased out with UWP so I figured I would learn what the new "right" way was.
I would of course not want to store DB info in a plain text file.
What is the best way to transfer that info from the WPF view to the Windows service?
You could basically create a new Windows Service (.NET Framework) project in Visual Studio and move your current code over to this one.
For more information about how to create Windows services, you should check out the documentation on MSDN:
How to: Create Windows Services: https://learn.microsoft.com/en-us/dotnet/framework/windows-services/how-to-create-windows-services
The service may connect to the database in the same way that the WPF application does since both are based on the same version of the .NET Framework.
If you want to share data between a client app and the service, you could for example use a database. You might use a local database or a plain file if the service and client app are deployed onto the same machine, or you may use a remote database if thet are not.
Related
Hi i have a C# WinForms app. I wrote essential methods on C#. But I need a login form and its not safe since apps like dotpeek can inspect the source code and hack it. Can i communicate with another application that is written in another language (java,c,python etc). I need to send input data from WinForms C# to another app then it should connect to database and check if login succesfull then return a value back to C# WinForms app. Is that possible, how can i implement that? I dont want to write all application in another language since C# has good methods to process images/pixels and gui support with very small memory usage.
I got the point you are trying to make.
One thing to admit is that you can't completely avoid decompiling of apps. C# or C++, no matter anything can be reverse engineered.
If you still need it, a comparatively safer approach is to not put the checking app at the client's machine. Create an API and host the database on a server.
Then initiate just an Http Request to the server from your Windows Forms app.
Then you have the full control of Login API and database. Many applications use OAuth similar to this. Another examples are apps verify it's license using an online API.
You can get a LightSail Windows server in around $10 a month if you want to setup. Try exploring
Your concern is not baseless. C#, or for that matter, any .net language running on the CLR, will be easier to inspect than a language like C or C++.
Having said that, no app will be completely secure, and communicating between apps has its own problems. How does one app verify the other? etc. You can create a web service that would communicate with the database (and communicate with the web service using HTTP or WCF) which would mean your app wouldn't have direct access to the database, but that would only protect the database from your app, it would still allow someone to inspect your app and use the web service, impersonating your app. Also, you would need to host the web service on some web hosting service, and then you would have to trust that service to not inspect your app...
You can reduce the problem by storing the password etc. as byte arrays, but regardless of what you do, I don't know of a way to completely safeguard your app. If a malicious app/actor is on your computer they can inspect your app.
As for your question itself - look into WCF or named pipes (includes a simple example).
I need to have a windows service that is configured with simple UI. I understand, that I need to create an API for windows service and use it in separate desktop application. But whatever I google I just got "you can't create UI to windows service" or info about webservice. I found this https://www.codeproject.com/Articles/1159908/Yes-I-Know-But-I-Still-Want-a-GUI-for-my-Windows-S but this seems to be a pretty bad workaround, because I can't use already started service in my GUI using it. What I need is some code, explaining how to create a connection between these two applications
After using Azure Mobile Services a year ago, I decided to get back to mobile development but Microsoft changed a lot in their offer and I'm actually struggling to set my project up.
My goal is to create a service whith these features:
.NET backend preferred over the Javascript one (I don't like callbacks :))
SSO (Facebook, Twitter, Google+, Windows Live)
SQL Database (I really need relations, and I already have a T-SQL schema)
Push Notifications (just to Windows and Android for now and with unlimited custom channels so that I can have one channel for each user and avoid dealing with notifications' logic)
Monthly scheduled jobs to update database from an external JSON API and to remove old entries
Mobile Client (with a shared Xamarin library to handle all the data-related stuff and WUP + Android support)
Web Client (I don't have a Mac so I can't build and publish the iOS version, so a web app may be needed as a temporary replacement)
What I did was to:
Open Azure Preview Portal link
Click on New => Web + Mobile => Mobile App
Set the Resource Group with all the needed plans
Added a Data Connection to a newly created SQL Database
Added a Notification Hub with settings for GCM and WNS
Added Mobile Authentication with settings for Microsoft Account, Facebook, Twitter, Google
Created the schema for my SQL Database
Before going on, I'm not sure that this was the correct workflow but documentation is pretty confused and the Get Started sections just discuss about code and not how to properly setup the service and have it running, so I just did the same basic things that I would've done with the old Mobile Service, plus dealing with the SQL Database instead of the NOSQL one.
Now it comes the issue: I have no idea on how to move next, and even the Quickstart projects (both server and client) are not helpful (they're the old TodoItem sample working with the Mobile Service).
The first thing that I wanted to do was to create the Scheduled Job because I actually need to fill the database with the external data before moving forward.
The only thing close to what I need is the WebJob, but I can't schedule it yet and it requires me to upload an exe file while I'd like to be able to write my C# code directly to the server (being able to remotely debug it).
An alternative may be to create a Compute Instace and write an endless loop doing what I need, but this will force me to manually deal with the SQL Database inside the Mobile App Service.
Another issue is related to the SQL Database. As I already wrote, the Quickstart seems to work with the NOSQL included in the old Mobile Service, meaning that I don't have a direct connection to my SQL Database, while I'd like to be able something like
App.MobileService.GetTable<MyTable>()
Plus, having 10 tables, I'd also like to have a way to map them automatically (like NetBeans does for JavaEE projects).
So the question is: what's a good (or the best) workflow to get everything working as I need it or, at least, close to how I need it?
(I know that answers may be opionion-based but they still may be useful since Microsoft's documentation is not complete)
If you have an existing database, you could use Entity Framework Code First to Existing Database. That will generate the C# classes for you.
The database that you create when you add a Data Connection to your Mobile App is an Azure SQL Database by default--I'm not sure why you thought it was NoSQL?
Once you have done this, you can query your tables from the Azure Mobile Apps client SDK. For instance, in Xamarin, the quickstart project does queries as follows (see https://github.com/Azure/azure-mobile-services-quickstarts/blob/MobileApp/client/xamarin.android/ZUMOAPPNAME/ToDoActivity.cs#L126).
var list = await toDoTable.Where (item => item.Complete == false).ToListAsync ();
Finally, regarding your question on WebJobs, you can actually schedule it. See https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/#CreateScheduledCRON for more information. Even though you Web Deploy your webjob target, you can still remote debug it. See this blog post for information: http://www.bursteg.com/remote-debugging-azure-webjobs-attach-a-debugger-from-server-explorer/
In advance, sorry for stupid question, but all search results in google are off-topic for me.
I want to create a C# application, that will run continuously on an Azure VM. It should NOT be event driven, as it will use different factors (db monitoring, time schedule, overall usage) to decide its activity.
Now, should I just create a console app in VS Express 2013 for Desktop and run it using RDP on VM? Or is there some azure-specific project that I can use (maybe for better integration with management portal)? All I can see and find is web-related (a website, a webjob, a background worker, a webapi), and mine app will not in any way be accessed remotely (it will periodically check db shared with a ASP.NET website)
It is possible. You should create the equivalent of a Windows Service, but then for Azure.
There is a useful question for that already on SO: Windows Service to Azure?
It has a reference to a full walk though: Migrating a Windows service to Windows Azure.
The corresponding azure type is "Cloud Services / Worker role". They work just as windows services.
So you can basically take all classes from your windows service (except Service1.cs) and put them in the new azure project.
The copy all start/stop code from your Service1.cs to the corresponding class in your new Cloud service project.
http://www.windowsazure.com/en-us/documentation/articles/cloud-services-dotnet-multi-tier-app-storage-4-worker-role-a/
In a situation where you have the UI frontend built using the new Metro style of apps for windows 8, and would like it to communicate with a .NET application running on the desktop on the same local machine (e.g. a windows service app).
What forms of interprocess communication are available between the metro app and the desktop app?
Thanks to Pavel Minaev of the Visual Studio team, who has provided some initial info here in a comment, quoted:
According to Martyn Lovell, there isn't any deliberate mechanism for
that, and some that could be used for it are intentionally restricted.
Named pipes aren't there, for example, nor are memory mapped files.
There are sockets (including server sockets), but when connecting to
localhost, you can only connect to the same app. You could use normal
files in one of the shared "known folders" (Documents, Pictures etc),
but that is a fairly crude hack that necessitates polling and is
visible to the user. -- Pavel Minaev commenting on this issue
So failing normal approaches I was thinking of using web services or reading/writing to a database in order to get some form of communication happening, both of which seem like overkill when the processes are running on the same machine.
Is what I'm attempting here making sense? I can see a need for a metro app to be the frontend UI for an existing service which is running on the desktop. Or is it better to just use WPF for the frontend UI running on the desktop (i.e. a non-metro app).
I'm porting my existing project to Win8 right now. It consists of windows service and tray application which are talking to each other via NamedPipes WCF. As you may already know Metro doesn't support named pipes. I ended up using TcpBinding for full duplex connection.
This post describes what functionality is supported.
Sample of my WCF server that Metro client can consume is here.
Also keep in mind that you can't use synchronous WCF in Metro. You'll have to use Task-based wrapper which is only asynchronous.
And thank you for you question. I was good starting point for me :)
There were a number of questions like this at the end of a //build/ session I attended. Aleš Holeček, the exec who did one of the big picture sessions, came up out of the audience to handle them. Even if you're not a C++ developer, download that session and watch the Q & A. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Metro apps can't count on desktop apps or services being installed on the machine. And desktop apps can't count on Metro apps running since they can be suspended any time. You need to start thinking differently. Listen to Aleš on this one.
Take note that with Windows 8.1 Update, communication between Windows Store apps and desktop components written in C# for .NET 4.5+ is now officially supported for side-loaded applications in Enterprise scenarios:
Brokered Windows Runtime Components for side-loaded Windows Store apps
To quote:
Recognizing that critical business functions and rules are embodied in existing software assets and that enterprises have a wide variety of scenarios for which the new application style will be highly productive, the Windows 8.1 Update includes a new feature called Brokered Windows Runtime Components for side-loaded applications. We use the term IPC (inter-process communication) to describe the ability to run existing desktop software assets in one process (desktop component) while interacting with this code in a Windows Store app. This is a familiar model to enterprise developers as data base applications and applications utilizing NT Services in Windows share a similar multi-process architecture.
Although implementing this approach is a bit on the complicated side initially, it allows for deep integration across Windows Store and desktop components. Just keep in mind that for the time being, it won't pass public Windows Store certification.
There is an article on InfoQ about how to build loosely coupled Metro apps with protocol handlers. This is something which has been supported by Windows for a long time and one could foresee an desktop application register itself as a protocol handler and maybe the metro application can communicate through this mechanism.
I have no idea if this is possible, but it might be interesting to check out.
Christophe Nasarre has blogged about a rather hacky way to do it using local files. The result is communication between desktop app/windows store app (referred to as DA/WSA in the blog), without having to switch between the UI of the two apps. He also blogged about another less hacky technique involving protocol handlers.
Note that having a WSA which communicates with a DA is explicitly forbidden by the store App certification requirements
Windows Store apps must not communicate with local desktop applications or services via local mechanisms, including via files and registry keys.
... but it restricts "local mechanisms" only. So I guess one can build a web service for routing the communications.
If you think that you can make an additional manual cmd operation,
you can try :
X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;
CheckNetIsolation.exe is included in winRT install, so there is nothing extra to be installed.
I tried it: it works, even after package updating.
As shown on: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx
Here it is explained how to find out the packageID for your app: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-
It is possible to communicate on the same machine from Metro app to desktop app using local service.
I've implemented some time ago simple "proof of concept", how to bypass the WinRT sandbox using local service. It still needs some kind of "social engineering" or direct guide for installing the service, but anyway, it is possible.
I'm not sure though about the certification rules about "local service" communication when adding such app to Windows Store.
Sample here
By design Metro application cannot access underlying PC directly, only using WinRT API and available capabilities. But when you create back-end service for accessing the PC and all data there, it's basically no longer running in sandbox.
The only "problem" is that user must manually install this back-end service, but that won't be a problem using some "social engineering":
User downloads "PC browser" Metro app, user can browse all pictures, music and videos, using WinRT API, but the app also shows message at the bottom:
"Download our PC browser powerpack and browse your entire PC, for FREE"
User is redirected to web page, from where user can download classic desktop installer containing "PC browser" back-end service for accessing files on users entire PC. Once this desktop service is installed, the Metro app can detect it and use it for browsing the entire PC. User is happy, but the WinRT sandbox is compromised.
Of course this won't work on Windows 8 ARM tablets. Using this workaround it could be even possible to build Metro app clients for classic desktop apps like antiviruses, torrent/P2P clients, etc.
Maybe I missed the point but when activating the Private networks capability I can connect to a local running (http) server using the local IP address (not localhost). This enables my scenario where a winrt app communicates with a wpf desktop app