I want to create a home-brew server farm, hosted on my own Windows 7 x64 box. There would be three guest 2k8 Servers, one each to run IIS, a domain controller, and SQL Server 2k8 R2. All guest machines would belong to a domain. The host machine is in a workgroup (not in a domain), and has Visual Studio 2010 Ultimate installed.
I want to know:
Can I remote debug (from the host machine in a workgroup) managed code on the guest OS (which is in a domain)?
Any complications if I'm using VirtualBox? I see a similar topic elsewhere, but it does not address the domain issue.
Can I use the VMWare Workstation "integrated virtual debugger" to do the same (debug managed code on guest OS)? Has VMWare started supporting this in VS 2010 yet?
Either way I need to take into account the workgroup-accessing-domain story I'd be dealing with.
You should be able to remote debug the guest OS's. Take a look at this article on MSDN for information on cross-domain remote debugging, which I believe still applies with the host not actually being on a domain. You simply ignore the fact either machine is on a domain and create like for like local accounts on the machines - all described in the aforementioned MSDN article.
If that creates problems for you, you can also disable authentication which seems to be a popular choice, despite being insecure:
http://communities.vmware.com/message/1617741
The article you linked in your post solves any networking issues so between that and the above you should be able to get the remote debugger up and running.
Is this question and answer any use regarding question 2? I can't find anywhere a mention that the integrated VM remote debugger is actually available for 2010, but then I can't find any posts complaining that it isn't. Perhaps it's just a closely guarded secret!?
EDI #19 or so:
Unfortunately I've found this article complaining that VS2010 isn't support by VSID. =(
Good luck!
Related
I constantly run into problems where a program runs fine on my system (installed and in development environments) but fails on a users system.
The best solution I can conceive is to debug the program on the users computer, but that's not practical since it would require me to install VS on their system and move the source code over (and doing so would compromise the integrity of the test environment anyway since it may cause the bug to vanish).
I want to remote debug but what I'm reading from the MSDN says to me "Nope, you can't do that unless both systems are on the same network (all. my. rage.)" :
Network configuration
The remote computer and the Visual Studio computer must be connected over a network, workgroup, or homegroup, or else connected directly through an Ethernet cable. Debugging over the Internet is not supported.
Is there another option I can use to connect to the process that is running on another system outside my network?
A partial solution (for the case that throws an exception).
Instead of trying to reach client app over the Internet, generate crash dump and debug it locally, in a comfort of your home :). Please see MSDN for details.
You can use a tunneling application (like hamachi). This will allow you to connect the other party like you're on the same network. Then you can use the remote debugging option. But even in local network remote debugging works slow and sometimes fail with code-optimized builds. Before using the "remote debugger" (by assuming there is any exceptions) I suggest to log all exceptions to a log file then watch the system. It will be helpful to put .pdb files to the remote system to see the relations between code.
I am using visual studio 2010 and I have searched on the net for help and other people using the DirectoryEntry("WinNT:") but it doesn't seem to work for me. I can see my network workgroups and if I use DirectoryEntry("WinNT://MYWORKGROUP") I can't see any computers listed.
Please help I am not sure why it isn't working for me.
Thanks
Getting computer names from my network places:
Do not use DirectoryServices unless your sure of a domain environment. The System.DirectoryServices class is an ADSI wrapper that dosent work without an Active Directory to query against. NetServerEnum() works on workgroups and domains but dosen't guarantee the most reliable data (not all machines may show up). It relies on the Computer Browser service.
To browse the local Windows network, NetBIOS name resolution must be running and correctly configured. In a corporate network that often means the presence of a WINS server. The required components are not enabled by default on modern Windows installations.
Before trying to do anything from your own code, ensure that the infrastructure is in place. Open Windows Explorer and expand the "Network" node. If name Windows browsing is correctly you should see the list of computers on the network there. If the list is empty, the problem isn't in your code.
So as the question goes, I have hosted a ASP.NET and C# website in IIS in my Windows 7 Ultimate OS. Not I need to be able to access the same site from ubuntu which is actually a virtualized OS running under VMWare.
I am able to access the website in my Windows 7 pc without any problems. But inside the Ununtu there seems no way to do the same.
I searched many forums for the same, no luck! Disabled the Firewall(Actually) to make sure no security issues arise but still not able to do the required thing.
This is the error :
Server not found
Firefox can't find the server at www.google.com.
Check the address for typing errors such as
ww.example.com instead of
www.example.com
If you are unable to load any pages, check your computer's network
connection.
If your computer or network is protected by a firewall or proxy, make sure
that Firefox is permitted to access the Web.
Any ideas?
the vm can access the host machine? if you use NAT connection mode seems cannot communicate with the host. Try Bridge instead?
We have an instance of SQL Notifcation Services for which we have written a custom delivery channel. We had this process up and running in our QA environment running Windows Server 2003 with SQL Server 2005. It took a little bit of tweaking to the get the custom DLL trusted however we got it all working.
We have since deployed this code to our Live environment. This runs Windows Server 2008 with an Instance of SQL 2005 for Notification Services but then we have an instance of SQL 2008 which hosts the actual DB instance for Notification Services. Notification Services works as it should however we cannot get the custom DLL to be trusted as a result the custom delivery channel won't work. We simply get the error
That assembly does not allow partially trusted callers
We have tried using the .NET configuration utility and caspol.exe to give the .dll full trust with no luck at all. The .dll is compiled as a .NET 2 dll as notification service requires this.
We are pretty much out of ideas at the moment and hoping someone can suggest something?
We have managed to fix our issue. It would appear that Windows Server 2008 is stricter in its implementation of code access. By giving granting access to the .DLL by it's strong name rather than it's path allowed Notification Services to access the code.
Notification Services was not at fault.
I think you have one of two choices:
Embrace SQL 2008 and get rid of Notification Services because it was deprecated. Use Reporting Services or SSIS to do what you need.
Revert back to SQL 2005.
IMHO, I'd go option 1. Continuing to build with deprecated tools is going to quickly find you in a situation where support (community or vendor) is going to be extremely hard to come by.
update
This was too long for comments.
Not to beat your head too much, but continuing to develop applications for a technology that was EOL'd (end of life) over 3 years ago was the first mistake. The EOL statement was made quite public.
The second was having a QA environment that is radically different from production. Before deploying anything to production, the QA environment should have been identical... same type of hardware, same OS's, same server versions and patch levels. Otherwise QA is a joke, as you've found.
Now, as to the "resolution", there really is only one path: Revert your production environment back to SQL 2005 with the appropriate patches in place.
I wish you luck.
It's been years since I've had such a hard time getting something to work. I'm at home, on subnet 192.168.50.nnn. I VPN'd in to XYZ company office machines that are on subnet 192.168.40.nnn, domain XYZ. I can ping the remote machines, I can net map their drives and copy files back and forth, but for the life of me I cannot remotely debug a C# program running on a machine called R (ipaddr 192.168.40.100, Windows Server 2003, IIS-6) from Visual Studio 2010 on my laptop (ipaddr 192.168.50.10, Windows 7, user XYZ\username, machine name L). I've read every MSDN article I can find, I've checked firewall settings, I unblocked port 135, I have the same user name and password on the two machines, I've tried running msvsmon.exe on R as a service and as an application (advertising itself as username#R), msvsmon has sufficient privileges, but I just cannot attach to any process on R. I can't even get a list of processes on R to show up. If I could pay someone to fix the problem I would, but I wouldn't pay a dime until I saw it working.
[Note: The IP addresses above are illustrative only, not the real values.]
I had a similar problem and my setup looked like this:
Client: Windows 7 x64 on a private subnet 192.168.1.x. Running Visual Studio 2010
Server: Windows 2008 R2 Standard SP1 with a public IP-address
Both client and server where stand alone. I.e. no domains, just workgroups.
VPN connection from client to the server and when I connected the client got the ip 192.168.0.131 and the server 192.168.0.130.
Turned off all firewalls etc. for the VPN connection, created identical users on the client and the server and identical password.
Ping, network shares, etc. working with no problems over the VPN connection. But I got the same error message from Visual Studio: "The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. A firewall may be preventing communication via DCOM to the local computer."
The solution for me was to change the workgroup name on the client to the same one as the server.
After that, everything worked perfectly.
You need to be authenticate on the same domain (or at least there be a trust relationship between the two) as the remote machine. Is the local machine attached to the domain on the other side of the VPN? If not, you cannot debug managed code using remote debugging.