I'm new to COM programming, and creating a basic native COM server / client pair from Visual Studio 2010. Both the client and the server projects live in the same solution. I'd like to know what the most appropriate way is to include the generated client stub and header file in the client project. I've created the MIDL in my server project, and when I compile the project the _h.h, _i.c, and _p.c files are generated in my project source directory.
Do I need to compile both of the .c files in my client project?
Is the best way to compile these in the client project by adding them as linked files in the client project from the source directory of the server project?
Is there a way for Visual Studio to know that the _h.h, _i.c, and _p.c files are out of date when I modify the MIDL, or do I need to remember to recompile the server project any time I touch the MIDL?
Where's the best place for the .h file to go - can it go in the stdafx.h file in the server project? If so, is it proper to add the source directory of the server project to the header include directories of the client project?
Should the client project have a "Reference" (in the Visual Studio Reference sense) to the server project?
Additionally - I'd like to make this registration free. Is there anything extra I need to do in this case, besides having manifests for my client and server?
..
edit
Looking at the MSDN article here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366830(v=vs.85).aspx, it appears that of the files generated, if I only want to support in-proc reg-free activation, I only need to compile the _i.c and include the _h.h files in my client program.
dlldata.c, and _p.c appear to be used to create a proxy DLL, which supports registration on a remote computer (for activation by a remote computer? or also local computer, out of proc? If it's required for local computer, out of proc, why is it needed given that the COM server's dll is registered? The COM server DLL is different from the proxy DLL, yes?)
Thanks very much,
--Matt
The generated _p.c and dlldata.c must be compiled into a separate project to build the proxy/stub DLL. You don't always need one, only when you marshal calls across apartments or processes.
The generated _i.c file provides the GUID values. Compile it into the server and the proxy/stub. Compiling it into the client is okay but using the __uuidof keyword is easiest.
The generated _i.h file contains the interface and coclass declarations. You'll need to #include it in the server and the client.
Midl.exe should automatically regenerate these files when you change the .idl. Which in turn ensures that client, server and proxy/stub get rebuilt.
stdafx.h is fine, yes on the include directory.
No on the "reference", the client and server have no link dependency.
You'll have to write the manifest for reg-free com and embed it in the client.
Related
I am trying to generate a gRPC client in C++, and have the generated client code built inside a Visual Studio 2015 DLL project. For some reason when building the generated gRPC client in a DLL a crash occrus when making a gRPC request, however building the generated gRPC client in a static lib does not.
I have a reproducible example that can be found here. The example contains the server to run inside the Dependencies\GreetServer folder, and two C++ projects:
GrpcDllTestClient contains a build event that uses protoc.exe to generate the client code from the proto file inside Dependnecies\GreetServer. The command runs of protoc.exe can be found inside the powershell scripts GenerateGrpcClient.ps1. The generated client code (.h and .cc files) are automatically included for build.
GrpcDllTestClientHarness is an exe project that references GrpcDllTestClient and uses the generated gRPC client code exposed from GrpcDllTestClient to fire requests.
The example contains two Visual Studio build configurations. Debug builds the GrpcDllTestClient as a DLL, which is the configuration where the crash happens, DebugAsLib builds the client project as static lib, which doesn't cause the crash.
When the crash occurs, following is the call stack that I can see:
> GrpcDllTestClientHarness.exe!gpr_atm_no_barrier_fetch_add(int * p, int delta) Line 101 C++
GrpcDllTestClientHarness.exe!grpc_core::CallCombiner::SetNotifyOnCancel(grpc_closure * closure) Line 189 C++
GrpcDllTestClientHarness.exe!grpc_call_unref(grpc_call * c) Line 604 C++
GrpcDllTestClientHarness.exe!grpc_impl::ClientContext::~ClientContext() Line 70 C++
I have installed gRPC using vcpkg with the following options:
set(VCPKG_TARGET_ARCHITECTURE x86)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)
set(VCPKG_PLATFORM_TOOLSET v140)
The options make vcpkg build gRPC libraries as static libs, targeting the Visual Studio 2015 compiler.
Any idea why building the generated gRPC client inside a DLL causes a crash if the client is used from outside the DLL? I'm happy to go with the static lib options, but interested to know if someone came across the issue before, and if there is a workaround.
I am new to networking and I am trying to make a basic client and server app.
I would like to know how I can structure my solution in visual studio for this.
What I have now is two projects - one for the client, one for the server. However, both the client and server use code from certain source files that are 'shared' if you would. Common purpose functions, etc.
Since both applications will need this code compiled, do I need to copy these source files in both the client and server project, or is there another, perhaps better way?
I am brand new to C++. I am creating AJAX files in the cgi-bin for maximum speed vs PHP.
My host is no help, I can find no docs on this, and searches return nothing (probably because of my limited vocabulary on the subject).
I want to upload cpp files to my WHM/cPanel VPS to compile for the cgi-bin. I have no idea what directory to put these for compiling or how exactly to do it.
How do I upload cpp files to a WHM/cPanel VPS, compile them, and move them to the cgi-bin?
Many thanks in advance!
You should put your compiled binaries (your C++ code must implement the CGI interface) in whichever folder your web server treats as active (i.e. CGI). If there is a folder where PHP files are run using the CGI interface, then putting the C++ binaries in the same folder should work (unless the server is set up with special filters to block running binaries for security purposes).
And yes. This isn't a very common problem. Though when I did it, it was very straight forward (I just dropped the binaries in and off it went).
On MSDN there is an example in C++ on how to create Dynamic virtual channel plugin.
My problem is that I don't know how to compile it.
Do I need to create an ATL project and in main.cpp copy-and-paste the code found on msdn? What do I call the project? If I create ATL project with name DVCPlugin, than Visual studio 2008 automatically creates DVCPlugin_i.h file, otherwise I don't have that file.
tsvirtualchannels.h is part of Windows 7 SDK so at least with that include I don't have a problem.
One of the errors I am getting is this:
&CLSID_DVCSamplePlugin not recognized identifier
I tried to create ATL project with the name DVCSamplePlugin but I received the same message as above.
Any suggestions I need to do to be able to compile that source code?
It took me a couple of hours, but I got the source for the client plugin to build using VS 2012. Here were my steps.
Start a new ATL Project named DVCPlugin. Select the option for a DLL.
Choose support for COM+ and check the box for the Object Registrar.
Add a file named GUID.cpp to the DVCPlugin project. include stdafx.h in this file.
ATL gave me a class named CompReg, which had its own IDL entries and GUID. I needed to associate that GUID with the CDVCSamplePlugin class.
In DVCPlugin.cpp, add the include for <tsvirtualchannels.h> to the top.
Paste the rest of the sample code after the definition of DllInstall().
Change the line DECLARE_REGISTRY_RESOURCEID(IDR_PLUGIN) to DECLARE_REGISTRY_RESOURCEID(IDR_DVCPLUGIN).
It looks like building the solution silently runs the registry script in the DVCPlugin.rgs file. I had to change the threading model to Free, though.
If mstsc.exe is 64-bit, you need a 64-bit plugin dll for the dynamic discovery to work.
This is just some code for testing Remote desktop connection -
There is an "echo" listener that is implemented by the Remote Desktop Connection (RDC) client, which is always present and listening for incoming connections. When you are writing the server side of a dynamic virtual channel (DVC) module, as a quick test you can open an endpoint named "ECHO". Any write to a channel that is instantiated from this endpoint will result in the receipt of the same data.
From MSDN.
Such projects are usually included in some SDK. And this one seems to be part of Windows 8 SDK
Update: After a critique from Tim (see below), i've decided to add these links with MSDN information -
Remote Desktop Services. TS-Teleport: Sample Instructions and
Remote Desktop Services Blog. Dynamic Virtual Channels
I'm new to developing in C++. I've developed a dll where I'm using curllib to make HTTP requests.
When running the dll via depend.exe it notifies me that my dll now depends on the curllib.dll. This simply doesn't work for me. My dll is set as a static library not shared and will be distributed on its own. I cannot rely on a user having libcurl.dll installed.
I thought by including libcurl into my project this is all that would be needed and my dll could be independent.
If this is impossible to resolve is there an alternative method I can use to create HTTP requests? Obviously I would prefer to use libcurl.
Thanks in advance.
You can compile curl as a lib instead of a dll by opening the solution file in visual studio and changing the build project to "lib release". Thus you wont need the dll at all and you can just include the lib in the linker.