I've created a simple windows service in C# using Visual Studio 2010. It uses a TcpListener and socket to listen for messages on a given port. This worked absolutely perfectly when my laptop had Windows Vista on it. However, since upgrading to Windows 7 and re-installing my service it only responds if I'm attached to the process and debugging in Visual Studio 2010 - at which time it behaves as expected.
I've tried running the service under my (administrator) credentials and setting the exe to run as administrator. I've also checked "Allow service to interact with desktop" when it was running under the Local System account.
I'm testing using both a test console app and an Adobe Air application - both with the same results.
Are there some specific permissions that I need to allow the service to be called?
Try adding an exception for your executable in Windows Firewall.
Related
I've written a Hello World console app in .Net Core 2.0 using VS 2017 and deployed the Debug build to a Raspberry Pi 3 running Windows 10 IoT. I can execute the app remotely via PowerShell and everything seems fine.
Having installed the Visual Studio 2017 Remote Debugging tools, I'm now trying to hook up the Remote Debugger so as I can step through my code on the Pi and I'm running into problems.
When I try to "Attach to process" from the Debug menu in Visual Studio and enter the IP and port number supplied by the IoT device portal I get the following error:
Unable to connect to the Microsoft Visual Studio Remote Debugger named '192.168.1.139:8116'. Connection request was rejected by the remote debugger. Ensure that the remote debugger is running in 'Windows Authentication' mode.
The following screenshot of the IoT Device Portal shows both the IP and Port for Remote Debug and the fact that my app (echo.exe) is running:
I've tried running the remote debugger both with and without the "Run as DefaultAccount" option checked, but this seems to make no difference.
I've also checked the firewall settings on my dev PC to ensure that it is not blocking traffic (I am connecting over the Private network)
Although the error message warns about Windows Authentication Mode, I can find no such setting for the remote debugger. Any help in getting the Remote Debugger attached and operational would be gratefully received.
You may need to select the connection type to "Remote" instead of "Default".
It works for me. You can have a try and feel free let me know if there is any problem.
One thing that I think it could help is when deploying the app to the Remote Machine and you are presented the ‘Remote Connections’ dialog you can choose there what type of authentication you want. One of the options is Windows Authentication. Try deploying and running the app like that and then the Remote Debugger should work.
In your VS Studio Project Properties -> Debug Tab -> Authentication Mode: Window Authentication
We have one Desktop application build with .NET3.5 in VS 2008. It is deployed on Network location which is accessible across the firm. Shortcut is created on user's machine to start the application. Desktop is being build (compiled) in AnyCPU configuration as Some user using XP machine and some are using Windows 7. Whenever new build (dlls and exe) deployed on network location, user have to close the app and restart it to work properly
Problem
We are facing a issue whenever we deploy new build (dlls and EXE) of the application. On Windows 7 machine application is not starting if we close the current running instance. User has to restart the machine itself to get it work.
Any help or suggestion is appreciated.
There is limited info to go on but the first thing I would make sure of, is the application still running under the Processes tab in the task Manager?
Go to the task manager on the computer and check the running processes tab to see if this app is still running.
It could be that it doesn't shut itself down properly after the user quits the application.
If the program is still running in the background then Windows will require a restart before the new dll's are loaded.
I have simple one Windows Forms project with one Main form in Visual Studio 2013 Update 4, on my dev Windows 8.1 Pro PC. I also have second computer (name: REMOTEPC) with Windows 8.1 Pro and installed Visual Studio Remote Debugging Monitor 2013 Update 4. I have configured Windows Authentication and firewall settings. I have configured project properties for Debug to use remote machine to REMOTEPC:4018 and in logs I see that user REMOTEPC\username connected. I use same local and remote paths (C:\proj\bin\debug\myprogram.exe) and have manually copied all files from directory.
Now I got error:
Error while trying to run project: Unable to start program (C:\proj\bin\debug\myprogram.exe). The MSCSMON.EXE does not appear to be running on the remote computer.
As I understand it needs only one TCP 4018 port and can not find a mistake. I have read MSDN info about this, but can not figure out why its not working. Is the remote debugging for Windows Forms or WPF possible at all ?
The solution is to use to configure firewall / port forwarding if needed, for both TCP 4018 and TCP 4019. I was missing one port (4019) and now it works without a problem.
What is the difference between using Visual Studio 2012 "Run as Administrator" mode and otherwise? Why do developers prefer using VS in administrator mode? What are the advantages/privileges that one gets?
I may be naive enough to ask this one but I am just curious. Thanks.
From MSDN: User Permissions and Visual Studio
You can do nearly everything in the Visual Studio IDE as a normal
user, but, you need administrator permissions to complete the
following tasks:
Installing Visual Studio.
Upgrading from a trial edition of Visual Studio.
Installing, updating, or removing local Help content.
Developing solutions for SharePoint 2010.
Acquiring a developer license for Windows Store.
Adding classic COM controls to the Toolbox.
Installing and using add-ins that were written by using classic COM in the IDE.
Using post-build events that register a component.
Including a registration step when you build C++ projects.
Debugging applications that run with elevated permissions.
Debugging applications that a run under a different user account, such as ASP.NET websites.
Debugging in Zone for XAML Browser Applications (XBAP).
Using the emulator to debug cloud service projects for Windows Azure.
Configuring a firewall for remote debugging.
Profiling an application.
Deploying a web application to Internet Information Services (IIS) on a local computer.
Changing how you participate in the Visual Studio Customer Experience Program.
Windows Vista introduced User Account Control which means that you are running all programs as a standard user even if you are an admin. There are certain things that you in VS that requires you to be running as an admin, not a standard user. For example running Windows Azure emulators, asp.net dev server, etc.
You can run VS as a standard user but sooner or later you will run into issues.
I am building a .NET 4.0 Web Forms application in C#. After working for around 4-5 months on this application, the other day when I went to 'Start' the application from Visual Studio 2010 and the application does not want to start. When trying to connect using telnet on the local host and that port, it connects, and after a while I get an error '400 - Bad Request'.
The funny thing is that when I Publish the application on another IIS server, it works fine, it seems like the problem is from the asp.NET Development Server. While I know that I can set-up a local IIS, I would prefer not to avoid doing this in order to avoid certain problems which might be related to having a different configuration of the local IIS from production.
I have checked the hosts file, re-installed visual studio and confirmed that the application works when published. I have also checked that the port is not being used by another process.
What else should I check?
If the application will not start, then the odds of you being able to connect to it via telnet on a port are 0. (It's not running.)
I am assuming the application can compile if you can publish it. Have you tried running the application without debugging? CTRL + F5