I have VS2015 with RTools and RTVS on a windows 10 machine.
I also have a Server 2012 with SQL Server, with R Server, and RTVS R Services installed.
I cannot connect the Win-10 RTVS to the RServer using Remote connections. I have done the following things:
On the Server:
Installed the Certificate
Installed R Services. Found both Services R Host Broker Service and R User Profile Service alive and running. The associated json is also set.
Found both programs listed on the Windows Firewall for allowed on inbound and outbound connections
Ensured .net 4.6.1 is set
On the Client Workstation:
Installed R Tools for Visual Studio on top of Visual Studio 15 (SSDT)
Installed Microsoft R and other related programs.
Copied and added the certificate from the server to the workstation's list of trusted certificates.
Ensured .net 4.6.1 is set
Added Server to Workstation's list of remote workspaces in VS. Called the workspace 'simulator'
I can telnet to rserver.domain.com with port 5444 to ensure port is listening.
however, when I go to connect to the remote workspace I get this error:
Connecting to R Workspace failed.
Reason: Machine 'Simulator' appears to be online, but the Remote R Service is not running.
>
I'm missing something, and don't know what. Where do I go from here?
Thanks.
Related
I have an ASP.NET website that is hosted on a client's web-server, which I used to be able to publish directly from Visual Studio with Web One Click Publish. The connection was made over FTPS, so would connect to the server's IP address on port 21; i.e. ftps://101.102.103.104:21.
However, after a recent update to the SSL cert on the server, I can no longer publish to the server from VS - I get the error below when testing the connection or attempting to publish the files:
The workaround I've got is to publish to a local folder and then connect with FileZilla to push the files up. The credentials I use are the same in FileZilla, and that doesn't have any issues with making the connection or uploading the files. So there appears to be an issue with Visual Studio publishing over FTPS with this new cert in place.
One initial difference I noticed with deploying via FileZilla was that upon initial connection, I would get a warning about the certificate mismatching the site name - but that was only when connecting by IP address. If I used the server name (which has the same domain as the wildcard cert on the server), it didn't display that certificate popup. Unfortunately, using the server-name in the VS publish settings still gave the same error.
While I was grasping at straws for a fix, I tried connecting on port 990 to see if I could use implicit SSL (a few articles mentioned this as an option), but this didn't work - I'm not sure if that port is blocked at the firewall or if there's just no service listening, but I can't telnet to the server on port 990.
I don't believe this is a limitation of Visual Studio as it was working before. Possibly our IT guys made some server-config changes at the same time as they applied the certificate? Has anyone else encountered this and were you able to resolve the issue?
So after some further digging, I found a Visual Studio problem ticket from January 2018 that indicates FTP publishing doesn't support TLS 1.2:
https://developercommunity.visualstudio.com/content/problem/190065/unable-to-publish-web-app-via-ftp-over-tls-1112.html
From checking the FTP connection to the web-server from FileZilla, it appears this requires a TLS1.2 connection. Therefore I assume that when the new certificate was applied, the TLS1.0 protocol was disabled on the server by IT, and that led to the FTP connection failing.
Hopefully if anyone else runs into this issue, they'll benefit from the knowledge that TLS1.2 is not currently supported in Visual Studio FTP publish (as at version 15.7.4).
UPDATE:
Can confirm that Visual Studio 2019 (v16.1.1) does support FTPS publishing using TLS1.2
When I'm trying to publish using Web Deploy (Visual Studio 2017 for Windows) to a Linux app service hosted in Azure the following error occurs:
Could not connect to the remote computer ("my-linux-api.scm.azurewebsites.net") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_COULD_NOT_CONNECT_TO_REMOTESVC.
The remote server returned an error: (405) Method Not Allowed.
The link in the error description seems to refer windows based hosts.
The service is up and running and responds to my request:
How can I fix that?
There is no Web Deploy on Linux. That's a Windows/IIS thing.
Push with git instead. The .scm. service (Kudu) knows how to handle the ASP.NET Core deployment on Linux.
I am unable to install Remote Desktop Session Host role while trying to setup a remote app on a virtual machine. It asks for a restart after completing the installation wizard but reverts back to the same state after the pending restart. Can't find any exception log file either (at %appdata%\Microsoft\Windows\ServerManager\ServerManagerExceptions.log). Any suggestions would be helpful.
Note:
A licensing server is also configured on the same virtual machine.
It installs just fine on a Windows Server 2012 R2 virtual machine.
Just had a similar issue. In my case I had partially disabled the firewall on the server. Re-enabling the full firewall, running the install, then disabling again worked.
I try to install remote debugger in my remote machine, and connect to it in my local computer, using visual studio 2012 for asp.net web application, windows8.
remote and local computers are not in the same network.
I installed the visual studio remote debugger in the remote machine and run it. it's instance name is:"SERVER-PC:4016"
In the local machine, I work on the project by ftp and in debug-attach to processor in qualifier field I enter the name in this format: external_ip:4016, and get an error:"The Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) does not appear to be running on the remote computer.."
p.s. I installed a local user in remote and local machine with the same name and password and run the relevant programs from this user name.
any ideas to solve my problem?
thank you!
My question is: why does a dev site work when the project is run in Visual Studio 2010, but not when served from IIS on the same PC?
I am trying to set up a dev copy of a client's site. On startup, the site makes a connection to a remote database server. The connection uses WCF and a SSL certificate to secure it. When I installed the site on my PC, following instructions, I installed a Cert Chain into the "Trusted Root Certification Authorities" and added registry keys and host entries to resolve connections to the remote service.
When I open the solution in Visual Studio 2010 on my PC and run it in the built-in ASP.NET dev server, it works -- my workstation connects to the remote service via SSL on a custom port (444) and the dev site queries for data successfully from the service. All of this is handled by a DLL provided with the project, and is outside my scope of work. I was briefed up front that the connection was very finicky about the SSL cert, system clock time agreement between the two machines, etc. and it took me a few tries to get it to work.
However, when I run the site in my local IIS (Windows 7, IIS 7.5) the site cannot connect to the remote service; the service won't accept the SSL connection. The startup code throws an exception when this happens, preventing the site from loading further.
Everything else seems to work fine: the only wrinkle is that VS requires a 32-bit version of the secure connection DLL while IIS on Windows 7 requires a 64-bit version. Both were provided to me and I swap them as required.
Per the comment, the answer is: check that the Cert Chain (to trust the SSL certificate used by the WCF connection) is installed to Local Machine (so that IIS sees it), not just to Current User (account used by Visual Studio).