Develop Reference

Properly configuring a dotnet (ASP.NET Core 2.1) environment on CentOS / Linux

I'm stuck, I'm really hoping someone can help or at least point me in the right direction. My end goal is to get my ASP.NET Core 2.1 app running on a CentOS Linux box. Since I'm using a mongo db in my actual app and wanted to eliminate any possible issues with that, I published a plain-jane asp.net core 2.1 mvc app, no authentication, and deployed it to a virtual host on my centos 7 box (apache upgraded via CoreIT to 2.4.37 since centos distros still deploy the older 2.4.6 version).
For the scope of this question I think I just need to make sure my reverse proxy is working properly and need help in pinning down that. I've followed instructions from here and the Microsoft setup doc from here. These 2 links are what I've been working with mainly.
When my app service is running, I can do a curl localhost:5000 and see the correct html of my homepage being returned. When I try from command line again with test.mydomain.com or test.mydomain.com:5000 it just times out. If I go to my app's conf (test.mydomain.com.conf in /etc/httpd/sites-available) and remove the ProxyPass, ProxyPassReverse and ProxyPreserveHost lines then I can hit test.mydomain.com from the outside with a browser and get my index.html file up and displaying properly (this is just one index.html file and not a part of the dotnet app though). It's only when I add the below back into my conf file it just hangs up when I try and hit the URL. I'm not sure what to look for in journalctl or maybe I should tail a specific log file to find out what it's waiting on and why it's taking so long.
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:5000/
ProxyPassReverse / http://127.0.0.1:5000/
Somehow is seems like my reverse proxy isn't set up right to be accessed from outside the box.
The rest of my app's config below.
<VirtualHost *:*>
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}</VirtualHost>
<VirtualHost *:80>
ServerName test.mydomain.com
DocumentRoot /var/www/test.mydomain.com/public_html
ErrorLog logs/dashboard.crtv1.com.errorlog
CustomLog logs/dashboard.crtv1.com.access_log combined
</VirtualHost>

I think I addressed the issue although I'm not sure what issues I was actually having at the time of posting. I ended up through process of elimination and curl to find another service was running and using port 5000 in another virtual host - we're doing development and need a test, staging and production set of virtual hosts. Also I found I had some code in my app (UseUrls) that was specifically stating to use port 5000 so multiple copies of it within the same environment had resource conflicts. I'll circle back and update which environments will use which ports and hopefully have a nice set up.

TF400307: The download operation timed out after waiting 600 seconds for a response from the server

Today suddenly we are getting the below error on TFS build for different files. In every tfs build attempt the file names are different.
TF400307: The download operation timed out after waiting 600 seconds for a response from the server.
Nothing has been change on the solution related to the project in which I am getting this error.
I am getting this in only one tfs build, other branches for the same source code are working fine.
Can anyone help on this?
Thank you in advance.

It probably due to some Cache file on the client Machine.
Please let the users who experience the issue clean the cache file on their client machine. The folder path is: C:\Users\username\AppData\Local\Microsoft\Team Foundation\5.0\Cache.
There is a similar thread here on MSDN Forum to follow up.

Access Denied when calling mc_login()

I stumbled upon MantisBT recently and got it set up at my workplace for future bug tracking. I wanted to make a neat little library we can use in our applications so that users can report bugs to us directly from the application in question.
Currently in a sandbox application I made to try and understand MantisConnect. I consumed the webservice successfully and I can make a client. But if I try and do this:
MantisConnectPortTypeClient client = new MantisConnectPortTypeClient();
UserData usrData = client.mc_login("omitted", "omitted");
I get a FaultException and the message "Access Denied"
Currently running Mantis 1.3.rc-dev.02
Any ideas on why this simple call is denied? It doesn't matter what user I use. It gets denied regardless.

Okay I figured it out.
The WSDL file on the server was still pointing to mantisbt.org instead of our local server. Changed it to our local server address and it worked fine.

Troubleshooting intermittent "No OpenID endpoint found" messages with Google and DotNetOpenAuth

I've been troubleshooting this one off and on for the past week. I've got a site using relying party MVC code from the DotNetOpenAuth project. I've been using this since 2009.
Recently, the Google logins have been failing. I'd say about 80% of the time the Google login works fine. So the intermittent nature makes this hard to diagnose.
Here's what I've tried:
Of course I've verified that the openid_identifier is using the correct URL ( https://www.google.com/accounts/o8/id )
I've updated to the latest release (DotNetOpenAuth 3.4).
I've tried adding default proxy settings as per this answer.
I've extended the timeout settings and even reduced memory on SQL to give IIS more RAM as this answer suggests.
I've added logging to every request and error to see if I could get any valuable information. This doesn't tell me much.
I've watched the requests/responses with Fiddler to see if I could spot anything.
I've tested my Google login on StackOverflow a number of times on the off chance that this is actually a problem with Google. And it's been working every time so far.
Any ideas?
UPDATE
In effort to pinpoint the problem I changed the code on my site a bit. Rather than doing this all on one line...
openid.CreateRequest(Request.Form["openid_identifier"]).RedirectingResponse.AsActionResult();
I broke it up into sections with logging in between...
MvcApplication.Logger.Info("Loading... " + Request.Form["openid_identifier"]);
var request = openid.CreateRequest(Request.Form["openid_identifier"]);
var redirect = request.RedirectingResponse;
MvcApplication.Logger.Info("Status... " + redirect.Status);
if (redirect.Status.ToString().ToLower() != "found")
{
MvcApplication.Logger.Error("Details... " + redirect.Body);
}
return redirect.AsActionResult();
So I'll be waiting for the next error.

I figured it out. This was being caused by New Relic. I'm not sure exactly how (or why it was intermittent) but that's what it was. New Relic automatically instruments your pages in certain ways so maybe it interfered with the request to the OpenID provider.
I looked back at the timeframe in which this all started and found that it was right around the time I installed New Relic on the server. So I uninstalled it, restarted IIS, and let the site go for 48 hours without it. I didn't get a single error in that time. So a couple hours ago I reinstalled it and sure enough I was able to duplicate the problem.
Anyway, I've removed New Relic again and all is good. I'll notify them about this.

Web service call slow from dev solution

Ok, I got an asp.net web service using WSE2. It runs on a xp machine.
And I got the front end asp.net application in my win7 machine.
both in Framework 3.5.
In production environnement everthing is fine.
The problem is, when I run the "developpement" version of the front end, web services calls takes forever. And by forever, I mean eternity. Here we count eternity in minutes.
By "developpement" version, I mean that I run the instance that is bound to the visual studion (2008) solution. I use the local IIS web server.
My first thought was for a network/firewall problem between my two machines. But if, form visual studio, I "publish" the site to another virtual folder, then everithing works fine.
So I have http://localhost/MyDevApp and http://localhost/MyPublishedApp.
Both uses default app pool. Both have identical web.config. As far as I know, both virtual directories have exact same parameters.
But http://localhost/MyDevApp is terribly when calling web services, and http://localhost/MyPublishedApp runs at light's speed.
It is like this since 3 days now.
Doing some debuggin I can say that :
MyWebServiceRequest request = new MyWebServiceRequest ();
request.Url = "http://mywebserviceurl";
request.RequestSoapContext.Tokes.Add (MyUsernameToken);
//All these previous lines executes correctly, rapidly.
//THIS is the slow one.
request.CallWebServiceMethod ();
Does anyone have the slightest idea what the problem can be?
Edit
I also tried changing the virtual directory from my web site's property to something different (say http://localhost/MydDevApp2), with the same result.
Edit 2
Maybe it can be in cause, the site binded to the solution reside in c:\Projets\MySolution\MyDevApp while the "published" one is under c:\inetpub\wwwroot\MyPublishedApp. The c:\Projets folder is excluded from the antivirus scans, so normally it should be faster rather than slower.
Edit 3
I created another workspace (the solution is under team server source control) in c:\inetpub\wwwroot\Other, changed the url of the web project, compiled and run : no problem. So it really seems that the physical path where the files resides is causing this, while the fact of beeing bound to the solution is not.
Edit 4 (August 19)
Well, it seems that there not much to do. It's been about 10 days since my last update, and now the site under the new workspace is beginning to slow down too. So I moved the workspace on disk, now in c:\inetpub\wwwroot\Other2, and you know what? That's running fine again. Perhaps I will have to move it again in about 10 days.
Edit 5
I flagged my question to move to serverfault, finally it does not have nothing to do with programmation, as I first thought.

Hard to say without seeing your machine in config, but often times it means you have some kind of a problem with your dns server or hosts file that is causing the process to be slow to resolve the service.
Also, if you are using a proxy server, make sure you are bypassing it for any urls that call the service.

Finally, it appears that wse2 traces where on :
<microsoft.web.services2>
<diagnostics>
<trace enabled="true" input="InputTrace.log" output="OutputTrace.log" />
</diagnostics>
<policy>
<cache name="policyCache.config" />
</policy>
</microsoft.web.services2>
While the log file was growing more and more, it slow down and down... just disabling the trace solves the problem.