I want my C++ application/process to be an HTTP server that listens to requests from another Java process. I am planning to use Microsoft's HTTP Server API for this, but the documentation says:
The HTTP Server API is supported on Windows Server 2003 operating systems and on Windows XP with Service Pack 2 (SP2).
Does this mean that this only works on Windows Server 2003 but not later? I am using Microsoft Window Server 2019 standard.
Also, the documentation says:
When you install the PSDK on drive C:\ of a local computer, the complete server sample application is installed at C:\Program Files\Microsoft SDK\Samples\netds\http\server.
PSDK was replaced by Windows SDK a long time ago, and I am not able to find any sample in the Windows 10 SDK, and also I could not find any sample for the same on GIT.
I am afraid that the HTTP Server API is deprecated, or I am looking at older resources.
Is there any other solution for my problem?
The requirements section (unless otherwise stated on the page) are always minimums. MS is very clear when something has been removed from the API (and even then is almost always a strong warning to quit using something rather than actually removing it).
Related
I have a legacy C++ (unmanaged) application build using VS2008 SP1. Currently, it makes calls to the web service hosted on an IIS, and the secure connection is made using SSLv3/TLS1.0. I am planning to make changes to connect using TLS 1.1. Internally, I am using WinINet calls to make connection. Does using VS2008 SP1 have anything to do with TLS1.1? Should I upgrade to a different version of VS (so as to get a new Windows SDK?) just to support TLS 1.1, or will it work with VS2008 SP1? Does anyone have any experience with this type of problem?
WinInet is no part of VisualStudio and it therefore does not matter if you use VS2008 of VS2015.
I cannot find a clear reference but basically you are using the libraries of IE. (A good hint for this can be found in the IPv6 section, here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=vs.85).aspx - "Starting with IE7 and above, WinINet supports IPv6 ...")
As you might have experienced already, on a system without IE installed some functionality does not work.
Since the WinInet (Windows / IE) supports TLS1.1 (and TLS1.2 for that matter), your program should just work. Even with VS2008.
Forcing the connection to use TLS1.1 or 1.2 is a whole other question ;-)
Just tunnel the connection throught something like stunnel or a vpn if You have access to client machines
I am looking for any information on the Microsoft TFS Web Services. First I know accessing the Microsoft TFS Web Services directly is not supported and Microsoft provides no documentation for doing this. Therefore I am not expecting any Microsoft support or assistance here.
I know all about the .Net API available for TFS which only works on Microsoft Operating Systems. I have used these many times on Windows, however I need to do non-Windows work to access TFS, I cannot use .Net and I cannot use a Proxy (or "shim") to be installed on a Windows computer to provide Web Services for the .Net API.
I know Teamprise reversed engineered the web services and they successfully used this knowledge to make a very good cross platform Team Explorer and command line implementation in Java to access TFS. So good in fact they were purchased by Microsoft and the product rebranded and rereleased as Microsoft Visual Studio Team Explorer Everywhere.
I have also tested the .Net API against Mono on several non-windows platforms and they are not compatible. The initial NTLMv2 authentication is using calls not supported by Mono. They appear to be, understandably, making Win32 specific calls for NTLMv2 support.
Therefore before I go to the trouble of reverse engineering them for myself, and dealing with NTLMv2 to do it. I am hoping that there is some hidden or buried information on the web that someone may have documented some portion of the web services for TFS from 2005, 2008 and/or 2010.
Please no comments or posts about how this is not recommended or supported by Microsoft, that I should find a way to use the .Net API, or suggesting the Proxy/Shim is the best solution. I am fully aware of the Microsoft's official stance on this, and what the supported workarounds would be.
I'm not aware of any documentation for the TFS web services, but I can share some tips on calling them.
The NTLM authentication you mention is really a separate layer: you must authenticate to IIS before it lets you call TFS web services. I'm not aware of any Open Source software that will do NTLM auth for you, but TFS 2010 makes it easy to enable "Negotiate" authentication (SPNEGO on Wikipedia, Authentication by using Kerberos Ticket on MSDN). Negotiate supports both NTLM and Kerberos subsystems, and there may be some existing software you can use to drive it using the system's Kerberos libraries (I think curl does it). If you had to build it yourself, it would probably be easier to go the Negotiate-with-Kerberos route.
Once you're authenticated, you can start calling services. Start by pulling down the WSDL for each service (stick a "?wsdl" suffix on each endpoint URI). Hop over to where TFS is installed and explore the web application directory for endpoints. There are several versions of some endpoints for back compat with TFS 2005 and 2008, but usually new versions are not redundant (they add new stuff). You might have a favorite SOAP client library already (there are many for Java), but I can't really recommend any because we wrote our own at Teamprise.
Services like version control, build, and common structure are easy to discover via WSDL. Most the operations have obvious names, but the complex type fields are often super-abbreviated. The best way to figure which methods to call when is to watch the VS TFS client or TEE with Fiddler or Wireshark or some other HTTP inspection program. TFS VC does do things like file uploads/downloads outside the web services (watch a network trace to see the multi-part MIME upload process and be sure you're sending the right values if you implement this).
A note of caution on the work item tracking web service: this one is going to be extremely hard to master. The WIT design involves the client pre-querying the server for large amounts of schema-less metadata, which is saved on the client (but refreshed incrementally as more web service calls are made). This metadata drives all the client side behavior about work items (what fields are in a work item type, the type of a field, which values are allowed in fields, the rules that run when they change, etc.) and it will take a long time and serious study to build the client behavior to bring a work item to life. Once you have a work item, sending it to the server for update via web services is easy.
It's a lot of work, but it's possible to do incrementally, for example, if you only need some VC features. The TEE team is working on making access from other platforms easier. Please contact Martin Woodward (martin.woodward#microsoft.com) if you have any questions or suggestions in this area.
There is a Java version of the TFS SDK that will run on Linux, Mac, and Windows. It is the SDK that Teamprise uses.
http://blogs.msdn.com/b/bharry/archive/2011/05/16/announcing-a-java-sdk-for-tfs.aspx
Coding directly against the TFS webservices is not supported (even though people have done it). MSFT could break the interface without letting you know in a service pack or other hotfix. Sometimes there aren't other options, but if the Java SDK works for you, I'd try to use that first.
There is good documentation now: https://www.visualstudio.com/integrate/get-started/rest/basics
I am using Micrsoft AppFabric caching Server in my web application and hosted using Windows 7 server. I am using Microsoft.ApplicationServer.Caching namespace in my web application. If suppose I have not used appfabic server used in window 2003 server this situation. This Microsoft.ApplicationServer.Caching namespace how will it support without appfabric server caching?...is there any option to support previous version server?
Havn't trouble reading your question but i think it pertains to versions of Cache Clients? If you have a 2003 client you need to install the 2003 client dlls see below:
Windows 2003
Windows Server 2008 and Up
As for server support, you have to have Windows Server 2008 or above... sorry.
I am working on Silverlight client to Microsoft Team Foundation Server. I am using an ASMX web service to make the actual calls using the TFS api.
Everything works fine when I run it with the visual studio development server, but I cannot figure out how to deploy the app to IIS.
I can get the ASMX web service to work unless it is a call that uses the TFS api. I have tried putting all of the TFS api DLLs in like every directory that I can think of, and even installing the visual studio sdk. Nothing works!
UPDATE 11/15/09 7:50PM EST:
Turns out that the TFS api was trying to create a cache at c:\Documents and Settings\Default User\Local Settings\Application Data\Microsoft\Team Foundation\2.0\Cache\, and the IIS_WPG user didn't have access to do so. Easy fix.
The only supported way of installing the TFS API is to install Team Explorer. You could try to GAC just the assemblies you need, but you're on your own [and technically violating the EULA]...
Other things to check:
IIS is running in 32 bit mode
Impersonation is working correctly
Proxy settings
What error do you get? Have you tried attaching a debugger to IIS?
I was reading up a little on the new Windows Web Services feature that is part of Windows 7, and I wondered if anyone knew if it would be available for use on Vista or XP (or Windows 2003 server)?
To answer my own question the answer is yes:
Its interesting MS are focussing on web services for native code, but also for devices with the WSDAPI and remote management services too.
edit:
turns out that you have to beg Microsoft to use it on any non-W7 system:
WWS API is available on all versions
of Windows 7 and Windows Server 2008
R2 and it can also be deployed to
Windows XP, Vista, Server 2003 and
Server 2008. The redistributable
installers are available on a formal
request to wwsredst#microsoft.com
with a brief description of plans for
using this runtime and the business
contact information for your company.
So, it seems gsoap is still the best solution for creating fast, low-memory web services.