I have successfully created a Windows Service in c# in Visual Studio 2010 on my local machine. I have to deploy it on the server that has only Visual Studio Express edition. This means no command prompt available with the VS. How do I install the service this? Should it be through the computer command prompt?
You don't need VS to get the service installed, nor does it help in any way. Windows still provides you with the command prompt of course. Be sure to start it by right-clicking the shortcut with "Run as Administrator" so you have sufficient rights to modify the registry. Then type the full path of the install command:
cd \where\you\copied\it
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe yourservice.exe
Replace "Framework64" with "Framework" if this is a 32-bit machine. Be sure to get the server admin involved, he probably cares about you making changes to the machine. Most do anyway. And he can be helpful of course, including getting the account+password you need at the UAC prompt.
You should make program install himself as a service when run in non-service mode, the most reliable way (to me) to do it is using some P/Invoke, see CreateService.
Related
I use a machine where I don't have administrator rights. I've been able to run programs without admin rights by extracting the program's .zip file to a directory I have created on my desktop. However, I can't find such a .zip file for Visual Studio.
Is there a way to install Visual Studio Community Edition without administrator rights?
Practically no. Visual Studio (Express and above, excluding VS Code) consists of multiple components that must be installed as admin, and will be required for the app you're debugging to be available as system-wide component. It might be possible to use ThinApp or its equivalent, but ThinApp can't even work with VS 2010 and it was by far the best of its class.
A (resource intensive) alternative to get VS on any PC will be packaging a VM with VS installed, either creating one yourself or get a ready-made ones. VirtuaBox is available as portable fork if you can't even get Hyper-V tools installed. But this still require kernel drivers installation, which means at least one-time admin access. Depending on your internet connection & budget, it might be more practical to setup a VPS with VS installed, then remote there.
Basically, youre going to need to download an iso of windows, then download QEMU, and run it as invoker by doing that batch file thing (https://techcult.com/how-to-install-software-without-admin-rights/). Set it to anywhere, and then figure out how to boot it to QEMU cause I have absolutely no idea how (ive only done it with Kali Linux). and just install VC on there. Sorry about being so vague.
There is no way to install or use Visual Studio on Windows without admin rights. You can either use a different program to write your code in and then compile using a different compiler. Or use qemu (since it does not require admin rights) to run a windows virtual machine.
I have been struggling to figure this out.
We have made a Outlook Add-In in Visual Studio 2013.
I can install this using the .vsto that they provide without a problem on a windows machine.
Now I try the same thing, placing the .vsto on the citrix server, installing this works fine, although it does a call to the internet which isn't allowed, so I had to work around that (anybody know why it calls to the internet? and what?).
Than I got it installed at the server, go to the thin clients, its right there, the only thing I have to do is activate it.
The second I activate it, it runs an executable, which obviously is not allowed, and I cannot activate it on the client.
You need to create an MSI installer for the add-in. See Deploying an Office Solution by Using Windows Installer for more information.
I am trying to remote debug my application in VMware workstation 7 and Visual studio 2010 ultimate. I habe several images (win 7 ultimate,vista,etc).
I am following this tutorial: http://kristofmattei.be/2010/01/20/debugging-applications-in-virtual-machines-with-vmware-workstation-7-and-visual-studio-2008-sp1-2/
Whenever I try to start msvsmon.exe on the remote computer it will say :
"The visual studio remote debugger does not support this edition of windows"
tried it with win 7 ultimate, vista premium and xp home, same situation.
Could someone help me out here?
Thanks!
The error message "The visual studio remote debugger does not support this edition of windows" appears because the remote debugger tries to use Windows Authentication by default, and this is only supported in the "Pro" versions of Windows, and up.
However, the remote debugger does work with the "Home" versions of Windows, you just have to tell it not to use authentication via the command line.
(Why it doesn't let you do this after launching it without any arguments, why the error message is so misleading (and contradicts the official list of supported OS), and why there is so little info about this on the web, I don't know. :))
To launch it, run this:
msvsmon.exe /noauth /nosecuritywarn
Of course, this launches it in the lowest security mode, so you'd only want to do this on a secure network. (But that's usually the mode one ends up using msvcmon in anyway, as the other mode is an even bigger PITA to set up than it is normally. Very useful tool, but really could use some streamlining.)
No need to use VMWare features.
Inside the guest VM run the version of msvsmon that came with your copy of visual studio 2010 (A setup package for just the remote deubgging stuff can be found on the disc/image) (use x86 if debugging a 32-bit process or x64 if debugging 64-bit one ,Itanium if you need to laugh).
through the msvsmon GUI disable authentication and select allow any user to connect.
disable the firewall in the VM.
on the host machine you should be running visual studio 2010, under the debug dropdown select "attach to process..." and then on the window that pops up select remote from the dropdown that should say local or something initially, enter the IP address (should be private network IP i.e. 10.1.?.?) of the guest VM, alternatively use the server name displayed by the msvsmon GUI. You should get the process list for the guest and should only attach to any process that matches the version of msvsmon you ran (x86 or 64 ...or Itanium laugh).
NOTE: These are basic instructions to show you it definitely works but these instructions will only work for native code since managed requires a secure connection.
If you are debugging a .NET app using the VMWare VS Plugin and are getting a "file not found" type of error...make sure you have the .NET runtime installed! :)
Like a moron, I set up a fresh XP VM and forgot to install the .NET runtime and wasted a good day trying to get the VMWare VS Plug-In to work!
VSID is not supported by visual studio2010 http://communities.vmware.com/thread/282407
I have a tool that I want to install on my main development box (Windows Server 2008). The installer tells me that it requires Vista. Of course I'm not saying Server 2008 is Vista, but I figure something that installs on Vista should be able to install on Server 2008.
Is there some way (perhaps via a temporary registry change) to get a server 2008 system to appear as Vista for the purpose of installing software?
Thanks!
Win2008Workstation has an example guide of how to use Orca to patch an MSI file.
Have you tried the emulator for running the install, when right clicking and going in to the properties of the installer?
right click > properties > compatiblity > and change the compatibility mode to Windows XP or Windows Server 2003
A few ideas:
If it's an MSI installer, download orca and delete the custom action that does the check
Use a tool such as process monitor to watch what registry keys the installer reads and tweak them to match vista's.
Is it possible to install the x86 Remote Debugger as a Service on a 64bit machine? I need to attach a debugger to managed code in a Session 0 process. The process runs 32bit but the debugger service that gets installed is 64bit and wont attach to the 32bit process.
I tried creating the Service using the SC command, and was able to get the service to start, and verified that it was running in Task manager processes. However, when I tried to connect to it with visual studio, it said that the remote debugger monitor wasn't enabled. When I stopped the x86 service, and started the x64 service and it was able to find the monitor, but still got an error.
Here is the error when I try to use the remote debugger:
Unable to attach to the process. The 64-bit version of the Visual Studio Remote Debugging Monitor (MSVSMON.EXE) cannot debug 32-bit processes or 32-bit dumps. Please use the 32-bit version instead.
Here is the error when I try to attach locally:
Attaching to a process in a different terminal server session is not supported on this computer. Try remote debugging to the machine and running the Microsoft Visual Studio Remote Debugging Monitor in the process's session.
If I try to run the 32bit remote debugger as an application, it wont work attach b/c the Remote Debugger is running in my session and not in session 0.
This works on my machine(TM) after installing rdbgsetup_x64.exe and going through the configuration wizard:
sc stop msvsmon90
sc config msvsmon90 binPath= "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe /service msvsmon90"
sc start msvsmon90
We had the same problem when trying to remote debug a website that is running as 32 bit inside 64 bit IIS.
You can also do this:
Stop the default debugging service
(which will be x64 as the installer
will have been clever and configured
that one to run).
Navigate to the Remote Debugger start
menu folder and run the x86 debugging
service. Ignore the warning about
32bit/64bit.
Open the Tools->Options window of the
remote debugger app window and make
note of the value in the 'Server
Name' text box.
Now you can attach your visual studio
to it by copying the 'Server Name'
value into the 'Qualifier' text/combo
box on the Attach To Process dialog
of Visual Studio.
On a related note, there is also a low-level bug with Kerberos authentication if you are attaching from Windows 2008/7/Vista to a 2003 machine, reported to MS (and then closed as 'external') via Connect here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=508455
I haven't tried this, but here's a suggestion anyway:
Try installing the x86 remote debugger service manually.
sc create "Remote Debugger" binpath= "C:\use\short\filename\in\the\path\x86\msvsmon.exe /service msvsmon90"
Two notes:
You'll need to use short filenames
in the path to msvsmon.exe to
prevent having to quote the path
(since the whole command needs to be
quoted)
there must be a space after the
"binpath=" (and no space before the
'=' character). Whoever wrote the
command line parser for the sc
command should be cursed.
Then you can use the services.msc control panel applet to get it running with the right credentials.
You'll probably have to stop or maybe even delete the existing x64 remote debugger service.
I can confirm that what you want to do will indeed work. I often connect my 32 bit xp worstation to a x64 win2003 server with VS2008 remote debugger.
1) Install the x64 version. This also installs the x86 debugger but does not create a shortcut.
2) You can find the executable for x86 process debugging here... C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe
3) If you want to, pin it to the task bar.
Worked for me without installing additional software. I just copied the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger folder on the VM and started the msvsmon.exe from the x86 folder. Both my guest and host are x64.
Sometimes this error occurred, I just close visual studio and open it again, everything is OK!
Very strange behavior from vs
I ran into this issue today (64 bit OS and VS 2019). I changed Configuration to use x64 for the project, IISExpress to use 64 bit and Platform target to be x64. It still used the 32 bit debugger and complained. Finally, when I enabled Script Debugging it started using the 64 bit debugger. So I would say the combination of all did the trick.