I’m using Windows 7, Visual Studio 2010 and AnkhSVN.
When I click “Add Solution to Subversion” and paste my repository URL into the designated field, nothing happens; I do not get asked to accept a certificate.
When I attempt connection via http (and not https), I’m asked for a username and password (as expected). As a temporary course of action, I simply accept the non-encrypted connection. After successfully committing my test files, I go under “Pending Changes” and click “Switch To” (the URL field) and choose “Other”. I change the address to https, and the following error message pops up:
An internal error occurred:
SharpSvn.SvnRepositoryIOException: Unable to connect to a repository
at URL ‘[my repository URL]’ OPTIONS of ‘[my repository URL]’: SSL
handshake failed: SSL disabled due to lack of entropy [https URL]
I've tried using both Assembla and Google repositories with the same result.
Back in January of this year, the last time I actually used SVN, I didn’t have this problem. When I load this old January project, it can no longer connect to the repository via https.
The only thing that’s changed since then, I think, is upgrading AnkhSVN.
This is caused by a bug in SharpSvn's compilation of OpenSSL when the LanMan Windows service is disabled. The bug has been fixed in recent AnkhSVN and SharpSvn versions.
Related
When I open vs installer to install updates, it asks to update installer first and then fails to download packages. I'm getting "Unable to download installation files. Check your internet connection and try again" error.
I tried to capture installer's requests with fiddler and it looks like it can't establish connection to https://aka.ms because of expired/wrong root certificate on my computer.
And I can't open aka.ms in browser, getting ERR_SSL_PROTOCOL_ERROR, which IMO proves that this is the issue.
I have latest windows version (20H2), no new updates in updates center.
How can I install new certificate to be able to connect to aka.ms? Where can I get it?
If you live in contries with strict Internet regulations (like Russia, China, Turkey) you should try using VPNs or proxies.
Regulators make ISPs to block some IPs/URLs. And some ISPs display their own stub webpages instead of the original web content. These stub pages usually says that you are not allowed to look at "restricted content". When using SSL/HTTPS some ISPs also try to response to your queries which can result in certificate errors.
Also it can turn out that some several IPs from MS IP addresses pool are blocked. And some MS functionality stop working.
I am updating from Windows 7 to a Windows 10 on a 64 bit system. I have no problems updating and checking out projects from the Subversion server on the Windows 7 box. I downloaded the latest 64 bit version and installed it on the Windows 10 box with no issues.
On the Windows 10 box I can post an update, but I cannot check out a project from the repository. When I attempt to logon the server I get the following error message:
svn: E170013: Unable to connect to a repository at URL 'https://svn.example.com/!/%23MyRepo/'
svn: E175003: The server at 'https://svn.example.com/!/%23MyRepo/' does not support the HTTP/DAV protocol
message that says The server does not support the HTTP/DAV protocol.
I passed the error message to the server manager and was told the problem was with the TortoiseSVN app settings. I cannot find a setting in the app that would address the problem.
Anyone have any suggestions on how I can fix this issue?
You get this error message because the URL is invalid. It leads to a web interface (i.e. a web client) and Subversion clients do not know how to parse this URL. Please, see the following article - KB102: Subversion client errors caused by inappropriate repository URL.
The comment by Bahrep is the correct answer, but since in the comments there seems to be some confusion, I decided to elaborate further.
"The error indicates that the URL used to address the repository using Subversion client is inappropriate. Most likely, the URL was copied from the web browser's address bar when exploring the repository through the web interface of VisualSVN Server. Subversion client programs are not capable of handling the syntax of such URLs. The appropriate URLs should be obtained by clicking the Checkout button in the web interface."
I got this error because I used browser link in the toroise interface, but I should instead click "copy repository url" in the svn and use that link. As simple as that!
I’m having trouble adding a reference to an HTTPS web service using Visual Studio 2008, it works fine in Visual Studio 2010 but in VS2008 I get the below error.
Our IT guys tell me that the problem is that VS2008 is not using the IE proxy settings properly so the HTTPS request is getting sent to the HTTP proxy, which always denies all HTTPS requests. However, in VS2010 it works just fine.
They don't know how to fix this if that is indeed the problem.
(As an aside, I have to use VS2008 because I want to use this in an SSIS Script Task, however I've been testing this in a blank console app.)
There was an error downloading 'https://xxxxxxxxxxxx.asmx'.
The operation has timed out
Metadata contains a reference that cannot be resolved: 'https://xxxxxxxxxxxxx.asmx'.
An error occurred while making the HTTP request to https://xxxxxxxxxxxxxxxxxxx.asmx. 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.
The underlying connection was closed: An unexpected error occurred on a send.
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
An existing connection was forcibly closed by the remote host
If the service is defined in the current solution, try building the solution and adding the service reference again.
This appears to be a bug in Visual Studio.
I am having trouble connecting Redmine to a locally hosted subversion repository using SSL.
I suspect it's the self-signed certificate that usually triggers a warning in the SVN client and browser.
When I try to connect to the local repo through SSL in Redmine, I get a red "Revision not available" error. When I try connecting through svn://, the connection times out, and I have to restart the web server.
Connecting without SSL works without problems.
It would be nice to run subversion on SSL to make it safely accessible from the outside as well. I could run the repository through plain HTTP but would like SSL for outside communication. As far as I understand, subversion can't be run both ways at the same time.
Does anybody know what to do in such a situation? Is there a configuration setting to ignore invalid certificates somewhere?
Looking at the source all redmine does is shell out to the svn binary, see: http://www.redmine.org/projects/redmine/repository/entry/trunk/lib/redmine/scm/adapters/subversion_adapter.rb
So if you can somehow workout how to get the binary to accept your SSL certificate then you will be good.
From http://groups.google.com/group/bitten/browse_thread/thread/d18b21a703c68344?pli=1 it seems you need some manual interaction with svn to accept the cert.
So my suggestion: run svn checkout against your repo as the user running redmine and permanently accept the cert
The reason you are getting this message is because the default user under which redmine is running (www-data) calls the “svn” client to communicate with the repositories but the client replies back to it saying that the certificate is untrusted, thus the connection is closed.
Here's a step by step fix:
http://haknick.tumblr.com/post/2380507902/redmine-svn-subversion-certificate-issue-ubuntu
since you control both the client and the server, is having the client accept the server certificate's issuing authority an option?
if it isn't a permanent option, at least you'd know if it was the problem if you did it temporarily.
I'm testing a ClickOnce application deployment. I have setup a virtual directory on my machine (running IIS). I have specified http://localhost/SampleApplication as the Installation Folder URL in the Publish tab of Visual Studio. However, when I publish the application I get the following error:
Warning: Files could not be downloaded
from http://chrish/SampleApplication/.
The remote server returned an error:
(407) Proxy Authentication Required.
Publish success.
Warning: Unable to
view published application at
http://chrish/SampleApplication/publish.htm.
http://chrish/SampleApplication/publish.htm
Notice how it has changed my url from Localhost to my login name. Why? This wasn't happening a week ago.
ClickOnce installation involves verifying that the server name matches the expected name. Thus localhost always gets translated under the covers to the computer name [not the username as you suggest in your question] (one of many confusing things ClickOnce does - one side effect of this is that if you want to set up 3 download servers, you need to do 3 separate publishes and/or script the publish like this) or like this. So this is not a surprise - it's always doing that under the covers.
The 407 error relates to proxy auth. This implies downloading is being diverted via a proxy such as Microsoft ISA Server. Have a look in your IE Internet Options Connections Proxy Settings and make sure its bypassing for local addresses [such as chrish].
The reason it's reporting success is that the upload likely uses an alternate mechanism than the verification does and isn't being routed via / blocked by the proxy. (The underlying problem is that the .NET framework does not by default pass proxy credentials and you'd need to either apply a config entry for devenv or whatever does the publish or have the build process call a test step with extra code that does send the proxy credentials](http://blogs.msdn.com/jpsanders/archive/2009/03/24/httpwebrequest-webexcepton-the-remote-server-returned-an-error-407-proxy-authentication-required.aspx). See also How should I set the default proxy to use default credentials?)
ClickOnce doesn't like "localhost", but you can work around that.
If you set the Publishing Folder Location to:
C:\inetpub\wwwroot\SampleApplication\
and the Installation Folder URL to:
http://chrish/SampleApplication/
(where "chrish" is the network name of your computer) then you can publish locally.