What's the best & fastest way to create an unmanaged Windows service with Visual C++ 2010?
Remark: From the lack of search results for this issue I'm suspecting this is either not recommended or trivial (a regular executable) - but I'm checking this for a colleague which insists not using the CLR.
I haven't tried it in VS2010, but it used to be fairly simple to create a Windows Service using ATL. As far as I remember there was even a project template for doing this.
Here's a CodeGuru article describing how to do it in VC++ 6.0.
Edit: Seems like it's still supported in VS2010 since it's still in the docs: ATL Services
Related
I'm using vc140_xp toolsets for supporting Windows XP.
Before Vista, there is a known problem which is occured in DLL using implicit TLS.
And, magic statics implementation of VS2015 uses implicit TLS.
Therefore, there is a need to turn off magic statics for developing DLL which supports XP.
For that, "/Zc:threadSafeInit-" is used.
What I'm wondering is that thread-safety of STL when using "/Zc:threadSafeInit-".
What I thought is that if in STL there is a code which uses static object in a function, the code may be thread-unsafe.
But, it is just my thought. And I can't find the exact description for that.
How is STL thread-safety going when using /Zc:threadSafeInit- in Visual Studio 2015 Update 3?
Can originally thread-safe feature of STL be going to be thread-unsafe if using /Zc:threadSafeInit- ?
If yes, is there no way for supporting XP and keeping thread-safety of STL, both?
I have a DLL generated from Visual Studio 2010, but I need to link it to a 2008 project that needs to remain 2008 for various other reasons. Anyone run into similar trouble or have advice?
VS2010 is .NET 4.0
VS2008 is .NET 3.5
So the answer for your question is NO because if the dll is making use of any of the specific .NET 4 features, it wont get executed in your 3.5 environment. Also it may happen that the assembly mapping is different in both the .NET version and that may become one of the reason for the 4.0 dll not getting executed in 3.5 env.
I am not sure, but you may look at COM Interop features. May be it can help you in achieving what you want. But it would be too messy !!
Dynamic-Link libraries (DLL) are an integrated part of the Windows platform from its very beginning. DLLs allow encapsulation of a piece of functionality in a standalone module with an explicit list of C functions that are available for external users. In 1980’s, when Windows DLLs were introduced to the world, the only viable option to speak to broad development audience was C language. So, naturally, Windows DLLs exposed their functionality as C functions and data. Internally, a DLL may be implemented in any language, but in order to be used from other languages and environments, a DLL interface should fall back to the lowest common denominator – the C language.
http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL
Standardized C style interface, should be ok, though that pertains only to non managed C++.
I am trying to create an windows application using c# look like Dotnet IDE. when i googling i have found some solution but that is not exact what i want. Anyone have any idea or have any refernce please share it with me.
Thanks in advance.
Your question is not entirely clear, but if you're looking for some kind of a .NET UI library with the same controls as Visual Studio (is that what you mean by "Dotnet IDE"?) you're unlikely to find one. This is because Visual Studio itself is not written in .NET - it's written in unmanaged C++.
Of course, it's possible to create controls that look and work the same way, but I'm not aware of any libraries like that.
I'm trying to create an absurdly simple shell extension in C++ using Visual Studio 2010, but I can't even seem to get the examples out there to work as a starting point.
I'm using Windows 7 x64.
I've tried this Visual Studio template, but once I get the template to work in VS2010, I have a host of errors that I'm not sure how to fix.
I've tried The Complete Idiot's Guide to Writing Shell Extensions, and once the demo compiles all the right registry settings etc. are created but no context menu appears.
I've looked at this C# COM Interop example, but I've been left confused as to whether it is safe to use C# thanks to this article*, but it looks like I might be OK if I use .NET 4 because it supports in process side-by-side CLR hosting.
in short: historically two versions of .NET cannot run in the same process, and the way shell extensions work is they inject themselves into a process. So if .NET 3.5 gets injected into a .NET 2 process - bang
So, can I use .NET 4.0 now?
Is there a working, downloadable, VS2010 solution that adds a simple shell extension?
I used to be not so bad with C++ back in the day, but after years of moulding to .NET I'm quite rusty, and as such, fiddling with the details to fix the host of errors I'm getting on the existing examples is proving... fiddly!
I could really do with a clean slate to start with that I can break myself and figure out what I did wrong!
I struggled with this for a while and had limited success with the code project article due to x64 issues and SDK differences.
I recently picked the project back up and started over using the MS all-in-one code sample and I am very pleased. It makes a simple example context menu and x64 works out of the box: http://code.msdn.microsoft.com/windowsdesktop/CppShellExtContextMenuHandl-410a709a
To get it running on your machine:
download the code via the all-in-one sample browser or use the direct link.
Open project in VS under admin rights
switch build config to x64 and build it
Kill all explorer sessions
Locate the new dll and run regsvr32.exe .\CppShellExtContextMenuHandler.dll
open explorer again and right click a .cpp file to see the new menu
remove it by running same command with /u flag
My next step is to get debugging working and I think this may do the trick: msdn
On Windows 7 x64 for a C++ extension you need to build it as an x64 project. In Visual Studio 2010 there is an option on the ATL Wizard to create a shell extension project that provides preview window support, thumbnails and Windows Search support. I recently used this and once built, nothing seemed to happen. However, switching the project configuration to build an x64 dll got it working.
With regards to using .Net - Explorer now launches plugins in a separate sub-process. So loading a shell extension that links to .net 4.0 does not contaminate everything with that version of .net as only the hosting subprocess will actually load that CLR. You can see this using a preview extension as a new process (prevhost) gets launched to contain this.
I got this one working: http://www.codeproject.com/Articles/174369/How-to-Write-Windows-Shell-Extension-with-NET-Lang
Make sure you use the right RegAsm.exe for de/registering it:
32-bit platforms: Compile for x86/Any CPU. Use C:\Windows\Microsoft.NET\Framework\vXYZ\RegAsm.exe.
64-bit platforms: Compile for x64/Any CPU. Use C:\Windows\Microsoft.NET\Framework64\vXYZ\RegAsm.exe.
(XYZ is the version of the .NET Framework you used for compiling.)
Note, however, that Microsoft recommends against using .NET for shell extensions.
The short answer to your 'can I use C#' is no. This is from Microsoft’s Guidance for Implementing In-Process Extensions. "One runtime of particular note is the common language runtime (CLR), also known as managed code or the .NET Framework. Microsoft recommends against writing managed in-process extensions to Windows Explorer or Windows Internet Explorer and does not consider them a supported scenario."
The problem arises because only a single version of .NET can be used in an application and there is no way to enforce that limitation if multiple .NET extensions are in use.
I am using the open source Saxon XSLT processor for .NET to execute some 2.0 transforms.
I reference the saxon9api.dll as I would any other dll, and can compile code against this. However Visual Studio does not show any intellisense making the IDE as useful as notepad.
The saxon9api.dll is using the IKVM Java for .NET platform, and I wonder if this is the causing VS a problem. Reflector can inspect the DLL without issue, but I suspect VS is not happy for some reason.
Any ideas?
EDIT:
Surprised that no one else has encountered this behaviour seeing as Microsoft recommends (link is now dead) the use of Saxon in the absense of built in functionality in the framework.
I think I will reword the question to be about assemblies running under IKVM not showing intellisense although I will need to find another IKVM based project to prove that this is the case first...
To make compiling, running and intellisense work in Visual Studio, you need to do the following:
Reference saxon9api.dll, as you already did
Reference IKVM.OpenJDK.Core.dll
Reference IKVM.Runtime.dll (not sure this is needed, but I always include it)
If you are also referencing vjslib, you may run into issues, because it uses a lot of the same namespaces and classnames, leading to ambiguities that can cause Visual Studio's intellisense to get into problems. Perhaps other libraries exist that show the same namespace clashes. In that case, try this on a fresh project first and add the references one by one, starting with Saxon's dependencies first.
After you do this, at least in Visual Studio 2010, 2012 and 2013, you will find that the context-sensitive help is working (image is of VS 2012 with R#):
Note: since this post is old, it may have only applied to Visual Studio 2008 at the time, I have not tested that as I am not using it anyore.