On the https://msdn.microsoft.com/library/windows/desktop/ms683502 page (v=vs.85) of .aspx/ it is written as to make that the service worked in an interactive mode. There it is written that it is necessary to cause the CreateService function. I not absolutely understand where it needs to be done. I use C# Visual Studio 2013 for creation of service from the Windows Service template, but there didn't find anywhere to execute required in article Microsoft. I ask prompt. Very much it is necessary to create interactive service on C#. I will be glad to any help.
A similar question has already been asked although unfortunately it might not be the answer you like.
In summary interactive services are frowned upon due to security risks and is not supported since Windows Vista. Although there is a documented workaround presented here which applies to C++ code where service is created using the WinAPI call of CreateProcessAsUser.
Other than the above, if you elaborate your problem a bit more we could provide alternative solutions.
Related
So I have researched through MSDN and SO, but have not found the answer to a question asked quite this way: I have an app that will be turned off/on, and as part of the install/update, I want to have a Windows service get updated as needed also as part of the install to the primary app. The Windows service will provide data to the app, but if the app changes, the service may need to provide more/different data.
I looked at TopShelf as someone suggested on a different post, and seeing that makes me wonder if I can use TopShelf to deploy the service at the same time as the app itself - in other words, wrap the whole thing in ClickOnce, let TopShelf do the Windows Service part, and ClickOnce finish by doing the app part. Does that sound like a decent strategy?
Ok, so I found my answer: ClickOnce doesn't do what I want, because Microsoft said so (under "Next Steps"). But their suggestion is to include a class called ServiceController which can talk to your service from your application, and do any Service manipulation that you want. (TopShelf doesn't appear to be necessary.) I like this because it allows everything to be under one roof, and is elegant...It should solve permissions issues and other barriers to simplicity of installation - we want this to be as easy and seamless for our
customer as possible.
I am intending to write code to determine if the OS is Windows XP, so I can set the LOCALAPPDATA environment variable to work-around a whole load of code which uses ExpandEnvironmentVariables() heavily.
To make it even more fun, some code is written in VB6, and some code is written in C# 4.0 . Looking at the documentation for GetVersionEx(), there are strong suggestions that this API call will be deprecated from Windows 8.1 onwards. But no problem, there is a different set of API calls (VerifyVersionInfo / VerSetConditionMask) I can use. With VB6, there is no choice - I have to use the API call.
However, with my C# code, there appears to be no obvious equivalent. There is Environment.OSVersion, but this seems to be a hacked together set of data from disparate sources, and there isn't anything with the subtlety of the VerifyVersionInfo() API.
Is there a wrapper for this API call. If not, should I bother implementating it myself?
[Added]
Or otherwise, maybe someone might have some internal information about how the Environment.OSVersion is implemented?
First of all it is important to understand what Deprecated means. It means that the function either is critically broken (such as some early threading), or that it's been superseded (replaced) with new functionality. In this case it is the latter.
From the documentation on GetVersionEx function there is a link suggesting to use Version Helper APIs instead.
One part of this page is specifically important:
Note These APIs are defined by versionhelper.h, which is included in
the Windows 8.1 Preview software development kit (SDK). This file can
be used with other Microsoft Visual Studio releases to implement the
same functionality for Windows versions prior to Windows 8.1 Preview.
It's perfectly fine to use GetVersionEx. It won't be removed from Windows for a very long time, if ever. Microsoft has a long track record of maintaining compatibility with old programs. For example, you can still call the Win16 APIs that were deprecated 20 years ago.
I added an additional part to my original question about whether anybody knew about the internals of the Environment.OSVersion object. After searching around this site for a few minutes, I found this question:
How to detect Windows 64-bit platform with .NET?
Now, the "official" answer itself wasn't very interesting to me, but the second answer from Phil Devaney mentioned an application called "Reflector" that appeared to do some sort of magic. So I downloaded it, and blow me down, I was able to decompile the P-Code for the Environment.OSVersion object's constructor:
Win32Native.OSVERSIONINFO osVer = new Win32Native.OSVERSIONINFO();
if (!GetVersion(osVer))
{
throw new InvalidOperationException(GetResourceString("InvalidOperation_GetVersion"));
}
So that's it: Environment.OSVersion internally uses GetVersion, a function which might not behave itself in future days. Looks as if VerifyVersionInfo and P/Invoke is the way to go on this one.
I will now have to download .NET 4.5 on a different machine and see if that implementation is any different.
Mark)
Maybe it will interesting for you GetVersionExEx
But please note that VerifyVersionInfo may also be deprecated in later releases of Windows OS (as stated by ms tech guy in msdn social forum).
This code depends on VerifyVersionInfo and provides same usage experience. Also bisection algo was used in code.
Version Helper API for requests to API, this code for exact values.
Thanks)
Has anyone successfully created a custom Windows Credential Provider in C#? The samples that are in the Windows SDK are all in C++. Some initial searching I have done indicates it may be possible but cannot seem to find anyone who has confirmed it.
+1 for pgina. As Cody says, there is no managed API you can use to make a Credential Provider, and if you want to go the pInvoke route it will probably take more of your time troubleshooting pInvoke issues than figuring out the Credential Provider.
Where pGina can help you is that it has a nice Plugin architecture and the Plugins are written in managed code. See the chart here. pGina handles the communication with LogonUI (native code) but relies on the plugins (managed) to do the actual authentication, which is probably what you want to control (otherwise you probably wouldn't need your own credential provider).
The new CredentialProvider model in Windows Vista and higher is based on COM. This means that it should be possible as long as you implement the correct COM interfaces.
Based on this, it should be easier to build than the older GINA model since the older GINA module used DLL entry points and function pointers instead of COM interfaces.
Given the ability for .Net to inter-operate with COM, it should be as easy as:
Building a C# definition of the ICredentialProvider interface and adding the correct COM attributes with the correct GUIDS
Building a credential provider class that implements the ICredenitalProvider and is marked as COMVisible(True)
Registering the new assembly with Regasm
Adding the correct registry keys to register your new CredentialProvider with Windows (Software\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers)
If you do all of that, you will have a working credential provider, written in C#
Check out pGina. I was playing around with it and it seems to work alright on my Windows 8 install, so it should work well with all Windows versions before that too. It is still in pretty early stages though and I can't see any way of creating a custom UI without having to delve into the native half of the project. Hope this helps!
[EDIT] Just read Cody Gray's comment again. To be clear, pGina is really just the native code written for you. But yeah, you'd probably have more control writing it in C++ to begin with, but if you don't need too much control as to how it is presented then pGina is the way to go.
I think it should be a windows service. when given certain conditions it should perform a login into the machine.
The machine will be in the "login screen" checking a webservice to know who is the user and password it should use to login.
Can this be done?, I don't want "automatic login" windows feature.
Thanks!
AFAIK this cannot be done as the login/authentication is done by the GINA layer (Graphical Interface and Authentication), you're effectively trying to replace that layer with your own, which would not be feasible from the managed side of code. In short, the only way to develop a replacement for the GINA layer would have to be done from the C/C++ side, not for reasons of speed, but because of the complexity involved in programming, a new GINA subsystem which would have to take into account of
Handling the authentication by interacting with WinLogon
Setting up a desktop
Loading Explorer as the shell
Doing it from .NET would not be a viable way of doing it. But nonetheless, if you are interested in replacing GINA with your own in pure C/C++ way, have a look here in the MSDN Magazine which published an article by Keith Brown, about replacing GINA with your own, in the May 2005 issue.
Edit: Thanks to Ruddy for pointing out this that I was not aware of, GINA has been replaced in Vista/Windows 7. Now, my view and of course this answer has changed to account for this accordingly, in short, to fulfill your goal and of course, to make this authentication backward if so wish for earlier version of Windows, ie XP (This may not be in your case, but worth mentioning). In Vista/Windows 7, GINA is replaced by a 'Content Provider', which I do not know about. But however, I have found this link to the MSDN about this here. Salvador - sorry if I cannot answer more about it as that's a new one to me! :(
Hope this helps,
Best regards,
Tom.
Problem
Language: C# 2.0 or later
I would like to register context handlers to create menues when the user right clicks certain files (in my case *.eic). What is the procedure to register, unregister (clean up) and handle events (clicks) from these menues?
I have a clue it's something to do with the windows registry, but considering how much stuff there is in .net, I wouldn't be surprised if there are handy methods to do this clean and easy.
Code snippets, website references, comments are all good. Please toss them at me.
Update
Obviously there is a slight problem creating context menues in managed languages, as several users have commented. Is there any other preferred way of achieving the same behaviour, or should I spend time looking into these workarounds? I don't mind doing that at all, I'm glad people have put effort into making this possible - but I still want to know if there is a "proper/clean" way of achieving this.
Resist writing Shell Extensions in managed languages - there are a multitude of things that could go bang if you pursue this route.
Have a browse through this thread for more details. It contains links to do it if really want, and sagely advice of why it can be done, but shouldn't.
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e/
You're back to unmanaged C/C++ as your only real tools here.
This is not a good idea because of potential dependency issues between different versions of the .NET Framework. Your shell extension could be expecting one version, while a different version may have already been loaded by the application that's currently running.
This thread contains a good summary of the situation.
While others already mentioned that writing shell extensions in pure .NET is a bad idea due to framework conflicts, you should still note that:
There are 3rd party drivers out there (see Eldos or LogicNP) that do the unmanaged side for you, allowing you to write managed code that talks to the native driver, thus preventing shell-related CLR version conflicts.
A recent MSDN article mentioned that Microsoft has solved this problem for the CoreCLR, as used by Silverlight. They've accomplished this by allowing multiple versions of the CLR to run in the same process, thus fixing the problem. The author further stated that this fix in Silverlight will be rolled into future versions of the full CLR. (Meaning, in the future, it will be quite feasible to write shell extensions in managed code.)
I've done them before in C#. It ends up being a hell of a lot harder than it should be. Once you get the boilerplate code down, though, it is easy to roll out new items. I followed this link:
Link To Info
As the prior comments mention, it isn't the best idea to write shell extensions in managed languages, but I thought I'd share an Open Source project that is doing just that :)
ShellGlue is a managed shell extension that is actually quite helpful. The source also might be helpful to you if you're interested in pursuing writing a shell extension in C/C++.
Aside from the caveats that have been mentioned concerning the implementation of shell extensions in managed code, what you'd basically need to do is the following:
First, create a COM component in C# that implements the IShellExtInit IContextMenu interfaces. How to create COM components in C# is described here. How to implement the necessary interfaces is described in this article. While the description is for a C++ implementation, you can apply that knowledge to you C# version.
Your COM component will have GUID called the Class-ID or CLSID. You need to register that ID with your file type as a context-menu shell extension:
HKEY_CLASSES_ROOT\.eic\ShellEx\ContextMenuHandlers\MyShellExt
(Default) -> {YOUR-COMPONENTS-CLSID}
Also make sure that you registered your component correctly as described in the C# COM tutorial. You should find it in the registry under
HKEY_CLASSES_ROOT\CLSID\{YOUR-COMPONENTS-CLSID}
InprocServer32
(Default) -> C:\WINDOWS\system32\mscoree.dll
Class -> YourImplClass
assembly -> YourAssembly, version=..., Culture=neutral, PublicKey=...
...
Good luck...
As others have pointed out, shell extensions are not practical in windows development currently.
I asked a similar question recently which was answered with a link to a guide to do exactly what I wanted to do