At my company we have recently set up a TeamFoundation proxy to our TeamFoundationServer. I have written a C# app, that connects to the TFS to query various things. Now, I want the app to support connection over the TFS proxy as well. As I am not really familiar with TFS, I am having some difficulties. Ideally, I want the application to only "know" the TFS proxy and have it act just like the normal TFS. Is this even possible?
What I am doing is something like this:
TfsTeamProjectCollection projects =
new TfsTeamProjectCollection(new Uri(serverUriString,
new NetworkCredential(username, password, domain));
This works fine if serverUriString is the TFS (e.g. "http://MyTfs:8080"). When I substitute this with the TFS proxy (e.g. "http://MyTfsProxy:8081") I get some unspecific TeamFoundationServiceUnavailableException, where at the end it states that a http 404 error occurred. The 404 doesn't make much sense to me, I am able to ping the server, I can connect to it from the browser and Visual Studio acceppts it as well. Do I need to set a connection to the TFS AND the proxy? If yes, how do I do that?
The AddProxy() method is used to register a list of proxy servers with the TFS server, so that clients can automatically detect & use a proxy server.
If you just want to configure your client to use a proxy server, there is no property to do this. You have to set a registry key or an undocumented environment variable.
For TFS2008 clients, the registry key is:
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\SourceControl\Proxy]
"Enabled"="True"
"Url"="http://someproxy:8081"
For TFS2010 clients, the registry key is:
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Proxy]
"Enabled"="True"
"Url"="http://someproxy:8081"
In either TFS version, you can set the undocumented environment variable:
System.Environment.SetEnvironmentVariable("TFSPROXY",http://someproxy:8081);
You can do this:
TfsTeamProjectCollection server = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri(serverName));
server.EnsureAuthenticated();
var versionControlServer = server.GetService<VersionControlServer>();
versionControlServer.ConfigureProxy(proxyName);
Related
How to setup a proxy in c# code for Google Text-To-Speech API.
Does somebody knows where to put in the proxy settings for the Google TTS API in c#. Our project runs locally but not on the server behind a firewall, so it has to go via the proxy.
Hope you have a starting point for me ;-)
Thanks!
The intention is that if you've set the system proxy, or the HTTPS_PROXY environment variable, that should just work by default.
However, at the moment there's a bug in Grpc.Net.Client that causes that to fail. (Once it's been fixed and released, we'll obviously update our dependencies for the next release of Google.Cloud.TextToSpeech.V1 and other Cloud libraries.)
The simplest workaround is probably to still use the Grpc.Net.Client implementation of gRPC, but with an additional option:
var client = new TextToSpeechClientBuilder
{
GrpcAdapter = GrpcNetClientAdapter.Default.WithAdditionalOptions(
options => options.HttpHandler = new HttpClientHandler
{
Proxy = new WebProxy("your proxy here"),
UseProxy = true
})
}.Build();
The docs indicate, that the default Proxy-Setup for the HttpClient will be determined through the presence of environmental variables and/or the system wide proxy settings.
I set the proxy-auth credentials like this:
setx http_proxy http://user:password#proxyIP:proxyPort/, and to be sure rebootet the system.
Since the Windows proxy-settings dialog does not allow to set username and password, i included there the proxy address and port.
Now i try to read them back though the CredentialCache with my C# app.
However the CredentialCache.DefaultCredentials are still empty and the proxy blocks and responds with 407 exceptions. Which is correct, since i cannot pass the credentials.
How do i have to setup the username and password to be able to read them from the CredentialCache?
I would like to be able to go this way, since very old code, long time ago shipped to customers, using a WebRequest object together with this settings is able to go through.:
UseDefaultCredentials = true;
Proxy = WebRequest.GetSystemWebProxy();
Proxy.Credentials = CredentialCache.DefaultCredentials;
Thats why i would like to also be able to write somethin to Windows that in turn gets read out of the Cache.
I've been writing a custom TFS 2013 server plugin for my company that automatically creates tasks whenever a new bug or product backlog item is created. While debugging I can see it detecting the new work item, but when it tries connect to the TfsTeamProjectCollection it throws TF30063 exception saying I'm not allowed to access the server. What baffles me is, in an attempt to see if the code after that worked, I made a simple client-side form application with the exact same code to connect to the server and it worked flawlessly.
The code I'm using to connect with is:
string tfsUri = string.Empty;
tfsUri = #"http://companytfsserver:8080/tfs/defaultcollection";
TfsTeamProjectCollection tfs = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri(tfsUri));
tfs.EnsureAuthenticated();
I've also tried manually setting the credentials, but no luck. Also, if it helps, I used this as my guide: http://geekswithblogs.net/BobHardister/archive/2012/10/08/automatically-create-bug-resolution-task-using-the-tfs-2010-api.aspx
I read through a ton of documentation of people getting the same exception, but none of what I found seemed relevant to this particular situation, so any help would be greatly appreciated!
*Update: After more digging and testing, it's possible it may have something to do with our application tier. I'll have to wait for the IT guy that's familiar with that particular system to get back from a conference (Monday, I think), but I'll update once I find out for sure.
**Update: I finally figured it out and I can't believe how simple it was. It turns out the URI that's used to connect via client app does not work when it's used in an app tier server plugin. Instead, it has to be localhost:8080/tfs/defaultcollection. Makes perfect sense to me now, but it never even crossed my mind before.
Just as jessehouwing says, since you are using collection uri "http://companytfsserver:8080/tfs/defaultcollection" You must have permissions on the Prioject(collection) with your account and TFS service account.
// Connect to TFS Work Item Store
ICredentials networkCredential = new NetworkCredential(tfsUsername, tfsPassword, domain);
Uri tfsUri = new Uri(#"http://my-server:8080/tfs/DefaultCollection");
TfsTeamProjectCollection tfs = new TfsTeamProjectCollection(tfsUri, networkCredential);
WorkItemStore witStore = new WorkItemStore(tfs);
I am facing a strange issue.I want to connect tfs server using tfs api programmitcally.
Even after giving proper authentcaion crediatials it is failing.But if I do it manually by typing tfs server name in browser its got connected.
code:
TeamFoundationServer tfs = new TeamFoundationServer(new Uri("http://10.112.205.145:8080/tfs"), new NetworkCredential(#"usrname", "pwd", "domain"));
tfs.EnsureAuthenticated()
Please suggest.
A simple way to do this is to add the "Syetem.Net" namespace to your code and then use the "CredentialCache" object. Using "DefaultCredentials" will Authenticate with the credentials of the active user.
// connect to the collection
using (TfsTeamProjectCollection teamProjectCollection = new TfsTeamProjectCollection("http://server:8080/tfs/DefaultCollection", CredentialCache.DefaultCredentials))
{
//Do Stuff here
}
Have you tried doing it this way..
TfsTeamProjectCollection collection = new TfsTeamProjectCollection(
new Uri(http://server:8080/tfs/DefaultCollection,
new System.Net.NetworkCredential("domain_name\\user_name", "pwd"));
collection.EnsureAuthenticated();
For your problem, normally you get an error like:
Possible reasons for failure include:
- The name, port number, or protocol for the Team Foundation Server is incorrect.
- The Team Foundation Server is offline.
- The password has expired or is incorrect.
The root cause of your problem is that the URI should be ended up with the collection name. So the fix would be, to change "http://10.112.205.145:8080/tfs" to "http://10.112.205.145:8080/tfs/%YourCollectionName%", then it will work! :-)
So I've got a ServiceReference added to a C# Console Application which calls a Web Service that is exposed from Oracle.
I've got everything setup and it works like peaches when it's not using SSL (http). I'm trying to set it up using SSL now, and I'm running into issues with adding it to the Service References (or even Web References). For example, the URL (https) that the service is being exposed on, isn't returning the appropriate web methods when I try to add it into Visual Studio.
The underlying connection was closed: An unexpected error occurred on a send.
Received an unexpected EOF or 0 bytes from the transport stream.
Metadata contains a reference that cannot be resolved: 'https://srs204.mywebsite.ca:7776/SomeDirectory/MyWebService?WSDL'
Another quandary I've got is in regards to certificate management and deployment. I've got about 1000 external client sites that will need to use this little utility and they'll need the certificate installed in the appropriate cert store in order to connect to the Web Service. Not sure on the best approach to handling this. Do they need to be in the root store?
I've spent quite a few hours on the web looking over various options but can't get a good clean answer anywhere.
To summarize, I've got a couple of questions here:
1) Anybody have some good links on setting up Web Services in Visual Studio that use SSL?
2) How should I register the certificate? Which store should it exist in? Can I just use something like CertMgr to register it?
There's gotta be a good book/tutorial/whatever that will show me common good practices on setting something like this up. I just can't seem to find it!
Well, I've figured this out. It took me far longer than I care to talk about, but I wanted to share my solution since it's a HUGE pet peeve of mine to see the standard. "Oh I fixed it! Thanks!" posts that leave everyone hanging on what actually happened.
So.
The root problem was that by default Visual Studio 2008 uses TLS for the SSL handshake and the Oracle/Java based Webservice that I was trying to connect to was using SSL3.
When you use the "Add Service Reference..." in Visual Studio 2008, you have no way to specify that the security protocol for the service point manager should be SSL3.
Unless.
You take a static WSDL document and use wsdl.exe to generate a proxy class.
wsdl /l:CS /protocol:SOAP /namespace:MyNamespace MyWebService.wsdl
Then you can use the C Sharp Compiler to turn that proxy class into a library (.dll) and add it to your .Net projects "References".
csc /t:library /r:System.Web.Services.dll /r:System.Xml.dll MyWebService.cs
At this point you also need to make sure that you've included System.Web.Services in your "References" as well.
Now you should be able to call your web service without an issue in the code. To make it work you're going to need one magic line of code added before you instantiate the service.
// We're using SSL here and not TLS. Without this line, nothing workie.
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
Okay, so I was feeling pretty impressed with myself as testing was great on my dev box. Then I deployed to another client box and it wouldn't connect again due to a permissions/authority issue. This smelled like certificates to me (whatever they smell like). To resolve this, I used certmgr.exe to register the certificate for the site to the Trusted Root on the Local Machine.
certmgr -add -c "c:\someDir\yourCert.cer" -s -r localMachine root
This allows me to distribute the certificate to our client sites and install it automatically for the users. I'm still not sure on how "security friendly" the different versions of windows will be in regards to automated certificate registrations like this one, but it's worked great so far.
Hope this answer helps some folks. Thanks to blowdart too for all of your help on this one and providing some insight.
It sounds like the web service is using a self signed certificate. Frankly this isn't the best approach.
Assuming you're a large organisation and it's internal you can setup your own trusted certificate authority, this is especially easy with Active Directory. From that CA the server hosting the Oracle service could request a certificate and you can use AD policy to trust your internal CA's root certificate by placing it in the trusted root of the machine store. This would remove the need to manually trust or accept the certificate on the web service.
If the client machines are external then you're going to have to get the folks exposing the service to either purchase a "real" certificate from one of the well known CAs like Verisign, Thawte, GeoTrust etc. or as part of your install bundle the public certificate and install it into Trusted Root certificate authorities at the machine level on every machine. This has problems, for example no way to revoke the certificate, but will remove the prompt.
Thanks for this great tip, took a quick look around at your stuff and you have a lot of good ideas going on. Here's my little bit to add -- I'm figuring out webMethods and (surprise!) it has the same problems as the Oracle app server you connected to (SSL3 instead of TLS). Your approach worked great, here's my addendum.
Given static class "Factory," provide these two handy-dandy items:
/// <summary>
/// Used when dispatching code from the Factory (for example, SSL3 calls)
/// </summary>
/// <param name="flag">Make this guy have values for debugging support</param>
public delegate void CodeDispatcher(ref string flag);
/// <summary>
/// Run code in SSL3 -- this is not thread safe. All connections executed while this
/// context is active are set with this flag. Need to research how to avoid this...
/// </summary>
/// <param name="flag">Debugging context on exception</param>
/// <param name="dispatcher">Dispatching code</param>
public static void DispatchInSsl3(ref string flag, CodeDispatcher dispatcher)
{
var resetServicePoint = false;
var origSecurityProtocol = System.Net.ServicePointManager.SecurityProtocol;
try
{
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Ssl3;
resetServicePoint = true;
dispatcher(ref flag);
}
finally
{
if (resetServicePoint)
{
try { System.Net.ServicePointManager.SecurityProtocol = origSecurityProtocol; }
catch { }
}
}
}
And then to consume this stuff (as you have no doubt already guessed, but put a drum roll in here anyway):
var readings = new ArchG2.Portal.wmArchG201_Svc_fireWmdReading.wmdReading[] {
new ArchG2.Portal.wmArchG201_Svc_fireWmdReading.wmdReading() {
attrID = 1, created = DateTime.Now.AddDays(-1), reading = 17.34, userID = 2
},
new ArchG2.Portal.wmArchG201_Svc_fireWmdReading.wmdReading() {
attrID = 2, created = DateTime.Now.AddDays(-2), reading = 99.76, userID = 3
},
new ArchG2.Portal.wmArchG201_Svc_fireWmdReading.wmdReading() {
attrID = 3, created = DateTime.Now.AddDays(-5), reading = 82.17, userID = 4
}
};
ArchG2.Portal.Utils.wmArchG201.Factory.DispatchInSsl3(ref flag, (ref string flag_inner) =>
{
// creates the binding, endpoint, etc. programatically to avoid mucking with
// SharePoint web.config.
var wsFireWmdReading = ArchG2.Portal.Utils.wmArchG201.Factory.Get_fireWmdReading(ref flag_inner, LH, Context);
wsFireWmdReading.fireWmdReading(readings);
});
That does the trick -- when I get some more time I'll solve the threading issue (or not).
Since I have no reputation to comment, I'd like to mention that Mat Nadrofsky's answer and code sample for forcing SSL3 is also the solution for an error similar to
An error occurred while making the
HTTP request to https://xxxx/whatever.
This could be due to the fact that the
server certificate is not configured
properly with HTTP.SYS in the HTTPS
case. This could also be caused by a
mismatch of the security binding
between the client and the server.
Just use
// We're using SSL here and not TLS. Without this line, nothing workie.
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
as mentioned by Mat. Tested with an SAP NetWeaver PI server in HTTPS. Thanks!
Mat,
I had such issues too and I have a way to avoid using certmgr.exe to add certificates to trusted root on a remote machine.
X509Store store;
store = new X509Store("ROOT", StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadWrite);
store.Add(certificate);
The 'certificate object' can be created like this:
X509Certificate2 certificate = new X509Certificate2("Give certificate location path here");