I've studied Windows Services and .Net framework.
From my research, a windows service is a type of application that is primarily used to run in background and can be done automatically or periodically. And
.Net is a software framework developed by Microsoft that runs primarily on Microsoft Windows.
What I would like to know where in the stack of the .Net framework are basically the windows services, supposing windows services use .Net framework.
Any further exaplanation on the relation between these two will be a great help.
Thanks.
They are two completely separate notions. They're related in the way that, for example, a hotel janitorial staff might be related to a guest of the hotel. Just because they reside in the same "building" at some point, doesn't mean there is any "useful" (i.e. substantive for the purposes of comparison given the context) relationship between them, though their paths may cross for whatever reason. The same goes for the notion of windows services and the .NET framework.
Windows services can be written in many languages, including .NET languages. .NET itself has a built-in project template for creating a Windows service.
based on your post:
"windows service is a type of application that is primarily used to
run in background and can be done automatically or periodically"
that is correct, as others mentioned above, you can use any framework to build those services.
Regarding the second portion of your question:
" .Net is a software framework developed by Microsoft that runs
primarily on Microsoft Windows"
Is exactly that, a framework, you can use this framework to create the above mentioned services.
A windows service is just an application that runs without user interaction, .NET is a set of tools you can use to build such applications.
You already have the answer you were looking for.
A service does not have to be written in .NET, anything will do. Two basic things need to happen. First of all, the Service Manager built into Windows needs to know that the service exists. That requires writing a handful of registry keys. Bare essentials are the service name, where the EXE is located and how it should be started. The ServiceInstaller class you write takes care of that, you run InstallUtil.exe to let that installer do its job. Have a look-see with Regedit.exe, navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services key.
And then the program needs to use a winapi function to talk to the service manager. So that the manager can deliver notifications that tell service to start, stop, pause, etc. That's wrapped by the ServiceBase class, you get friendly methods you can override. Like OnStart(), etc.
That's all there is to it. The service manager takes care of the heavy lifting.
A windows service is a type of application that has been around a long time before .NET.
You can write a Windows Service in many programming languages. You can write a Windows Service in .NET and a language making use of it (C#, VB.NET, etc) but that is not required. You can also use other languages that do not use the .NET framework to write a Windows Service.
Related
I got project that will run on windows and web. I wonder if there is a solution to create that as a cross platform application . If you have any experience or any solution please let me know.
Create web service(s) for your business.
Consume them in both windows application and web application.
Configuring is the key here.
When it comes to consuming web services,may be little challenging for authentications, authorizations and marshalling data, but it is possible.
You can choose any programming language for creating web services. But languages like Java, C# or vb.net has good supporting libraries and easy to do. Any how your question tag says C#, dotnet frame work has good support for webservices using WCF.
You can share a lot of UI code between a desktop and web application using a framework like Electron. This is the method that a lot of popular products with both web and desktop apps (like Slack, Discord, and Ghost to name a few) use.
We have a big application in .Net 4.5, with WPF and a lot of references like NHibernate, Fluent NHibernate, Enterprise Library, Unity and others.
I was asked to investigate whether we can run this (after some work done) on Windows 10 IoT. As far as I know I need to port the app to Windows Universal App, and as I understood this is impossible as NHibernate won't work for Universal App.
WPF is not a problem though as we agreed we can throw frontend away if we have to.
So I wanted to ensure my understanding is correct and the only way to run our app in Windows 10 IoT is to rewrite it without NHibernate and all other 3rd party libraries that currently do not support Windows Universal App. Is this true? If no what should we do to make it work and does it require a big effort?
If you have a core with all the functionality in it and its separated from the front end it should be possible to use that core and then build a new front for it with UWP.
The UWP is more limited regarding access to libraries and frameworks due to it being adaptable by several platforms so might need to rewrite some platform specifik code.
So the answer depends on how coupled and platform specific the code is as it is now.
I started work on porting an application I've written for deployment in the Windows 8 app store. This requires that the application be written against the subset of the .NET framework. My application follows an architecture where the core functionality is in it's own dll, and things like file system access are done through IoC. Basically, this means that the only dependency for the core dll is System. Because of this, I thought that porting would be a breeze - setup my IoC values and wire up a GUI then I'll be good to go. Only, I can't even reference my core dll from the windows store app (a.k.a. metro app).
Have I missed something? Do actually have to rewrite my core dll just for inclusion in the windows 8 app store? We're told that if you use a good architecture, then porting will be a breeze, and that's what I've done. Has that just been a big lie?
Windows store apps(formerly called metro style app) are limited to using the .NET Core Profile. I put some details about the Core Profile in my answer to this question. See Converting your existing .NET Framework code in this article more details. It's not your architecture, it's the subset of the .NET Framework that is available to a Windows store app. You may have to supplement some of the types you use in .NET with WinRT types instead.
I don't have an extensive knowledge and will try to stict to facts as I understand them. The Metro framework adds functionality, and limits functionality. There are heavy security restrictions and vast segments of the full .Net framework that are not available (for instance, you cannot use System.Data, some of the System.IO and file access methods have drastically changed). A Metro app is isolated, you're not going to be able to recurse all the files on the hard drive like you could in a standard application (my opinion that is, on top of security by isolation it's an encouragement to push you into the cloud for storage needs).
Unless things have changed, PInvoke is limited to "approved" Win32 API methods.
See this link for some alternatives to common Win32 API needs: http://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
See this link for approved Win32/COM API's: http://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
It's hard to say whether a "good" architecture will be a breeze to port without knowing what's in the code in that architecture. In my utility framework I've had things that ported very easily (or at least were straightforward) and things that were a complete wash that required a lot of rewriting (The loss of System.Data for instance is a sore spot for me). There are things that can be designed well but when you take out the underlaying code in the framework or API it was written with it will require rewriting.
I had the same problem: a project for Metro app don't load dll create with framework .4. I changed the framework from 4 to 3.5 for the dll and now the Metro project see them.
I'm pretty excitet about all the new stuff coming up in Windows 8, but at the same time a bit worried about how and if I can continue use the code and custom components I have already built up using .NET and C# during my time as a Windows dev. I've got some general mixed questions about this. Hope you don't mind I'm putting them together in one post:
Will Windows 8 Store be for both metro-style apps and regular WPF-desktop apps? Including pushing updates and making apps available for company employees?
Will the new App Contract-thingy also be available for WPF-apps? And is AppContract based on WCF-services with perhaps UDP-discovery on the network? Can I make my own contracts between my own apps using the App Contract framework?
I'm not particularly worried about if WPF will be ditched or not. I can live without it. The thing that worries me is if I still can write presentation and business-layer code in C# and use it as a backend for my apps, no matter what UI-framework I'll be using, HTML, Silverlight, WPF or what have you. If I'm still able to write logic in C# and present it using X UI-framework, I'm a happy developer. I've heard I can access the .NET-framework from JavaScript. But what about custom assemblies?
It has been announced that non-Metro apps can appear in the store but the store will just link to the publisher's website - not actually manage the sale/install/DRM/etc stuff.
What's been announced so far is that the contracts are only for Metro apps but I'd be shocked if this doesn't change. It would be crazy for Microsoft not to allow desktop apps to, for example, add commands to the Settings charm, support PlayTo or printing through the Devices charm, or act as Share sources. We'll have to wait and see where they draw the line on what desktop apps can/can't do.
Sharing code between Metro and non-Metro apps is going to be very difficult. A lot of the core concepts and conventions are the same but even basic stuff like file I/O rely on a totally new API. There aren't a ton of interesting things you can do with in code that will work on both sides of the fence. Best bet would be to define interfaces for your business layer stuff and then use dependecy injection to dynamically select desktop vs. winrt implementations at runtime
Store: there is no final information but as far as I understood it, it's for metro style applications only
The app contracts are a metro thing. I know a code snippet that documents usage from desktop apps (eg http://www.heise.de/developer/artikel/WinRT-in-klassischen-NET-Anwendungen-nutzen-1366039.html (sorry, German)), but I do not know if it will have support from Microsoft
WinRT compiles libraries to WinRT components. You might be able to reuse code and compile them to a component as long as you're not using a namespace that isn't available for WinRT
This question is heavy on guessing as there is no official beta available. And even then we can't be absolutely sure...
I'm developing an application for a Windows based tablet PC. This application is pretty much a port of an application I already developed on a Windows Mobile device using .NET CF. I want to write the application from scratch, taking advantage of all of the knowledge I've gained in software development.
I'd also like to write this new application in such a way that if I so desire, I can modify my existing Windows Mobile app to use the new libraries. Ideally, I'll have a shared set of business logic and data access libraries, with the only real difference being the UI layer - WPF for the tablet version, and just a standard CF interface for the Windows Mobile app.
Taking this into account, I'll need to make sure that all of the projects I create are compatible with the .NET Compact Framework. Is there an easy way to ensure this? One thought I had was to use a Smart Device Project for each class library that I create.
As well as this, is it easy for me to reference these libraries written for a .NET CF application from a standard windows application?
Is developing an application for a tablet PC the same as developing any normal windows forms application? Is there a different version of the .NET Framework to take into account, or are tablets pretty much standard windows pcs?
There isn't a special version of .NET Framework for Tablet PC. The question of sharing code between Windows Mobile and Windows has been asked before and the accepted answer is excellent.
The tablets I've seen are running standard Windows with the "full" .NET, but I expect you can get some light-weight devices, too. One interesting possibility might be "client profile" (a subset of the regular "full" .NET dlls) - but I haven't seen much use of that myself.
CF and regular .NET share a lot of things, but ultimately there are differences; neither is a strict subset of the other. I've found that in general the only way to write code for 2 frameworks is to keep both active... for protobuf-net (which has this problem) I keep a project file for each framework so that I can quickly test that the build works everywhere (i.e. there are no missing methods etc).
You may find you need to use #if blocks to run slightly different code on the two frameworks, especially if you want to use "full" .NET features for performance reasons (that don't exist in the CF version). One way of making this easier it to hack the proj files to use recursive file inclusion:
<Compile Include="**\*.cs" />
Now you don't have to keep adding new files to both projects - it'll get picked up automatically (caveat: in the IDE you may need to unload/reload the project).