<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>What are your remote debugging scenarios?</title><link>http://blogs.msdn.com/b/greggm/archive/2004/06/22/162546.aspx</link><description>I am constantly using remote debugging. I have one &amp;#8216;development&amp;#8217; machine. On this machine, I have Visual Studio 2005 and an environment setup to build whatever version of VS I want. Then I have a bunch of test machines which run debug versions</description><dc:language>en-US</dc:language><generator>Telligent Evolution Platform Developer Build (Build: 5.6.50428.7875)</generator><item><title>蛙蛙推荐：几种典型的生产环境调试场景</title><link>http://blogs.msdn.com/b/greggm/archive/2004/06/22/162546.aspx#9006211</link><pubDate>Sun, 19 Oct 2008 15:03:49 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9006211</guid><dc:creator>蛙蛙池塘</dc:creator><description>&lt;p&gt;生产环境的调试不同于开发环境的调试，生产环境一般受条件限制，无论是在线调试还是抓dump，都不是很方便。比如生产环境的一个windows服务,你想用vs.net进行远程调试；比如你想让某个性能计数器达到一个值后自动抓dump；比如你想让某进程崩溃的时候自动抓dump，比如你想在程序里动态的生产进程的minindump；比如你想在iis应用程序池回收的时候自动抓取Dump。&lt;/p&gt;
&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=9006211" width="1" height="1"&gt;</description></item><item><title>re: What are your remote debugging scenarios?</title><link>http://blogs.msdn.com/b/greggm/archive/2004/06/22/162546.aspx#185757</link><pubDate>Fri, 16 Jul 2004 22:57:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:185757</guid><dc:creator>Gregg Miskelly</dc:creator><description>Share out the whole installation: I agree with you that that was a nice feature that we lost when we moved to devenv.exe (instead of msdev.exe). However, currently, that is impossible. VC6 got away with that because it wasn't a COM application. On the other hand, the debugger, and pretty much everything else in VS requires registration to work. We did a lot of work to make regular debugging work remotely without registration, but we are still far a way from a registration-less world. Maybe when we move to all managed code we will do that.&lt;br&gt;&lt;br&gt;Performance improvements: I hope so.&lt;br&gt;&lt;br&gt;Connect As: We would like to do this, but we have to scrap our current architecture first.&lt;br&gt;&lt;br&gt;Share out debug libraries: All of the VC shared libraries now require fusion, so they need to be installed (as opposed to xcopy installation). If you want to run your product without needing to install the debug CRT, I strongly recommend using the static CRT.&lt;br&gt;&lt;br&gt;Ports: We actually use multiple ports in /noauth mode. However, starting with XPSP2, the Windows Firewall allows you to open up ports by the name of the exe instead of by port number. &lt;br&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=185757" width="1" height="1"&gt;</description></item><item><title>re: What are your remote debugging scenarios?</title><link>http://blogs.msdn.com/b/greggm/archive/2004/06/22/162546.aspx#181161</link><pubDate>Mon, 12 Jul 2004 22:48:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:181161</guid><dc:creator>Mark Nicolini</dc:creator><description>Being able to debug VS2005 managed code using MSVSMON (like native) would be helpful.  But are there any thoughts to having the ability to share out an installation of VS2005 for remote debugging only, like what could easily be done with a VS6 installations, without having to use MSVCMON\MSVSMON?  Losing the ability to run off of a share installation of VS when upgrading from VS6 to VS7 was a big impact on remote debugging.&lt;br&gt;&lt;br&gt;If MSVSMON is going to continue to be the only way to remotely debug with VS, then are there any debug performance enhancements to MSVSMON, especially the network communication layer?&lt;br&gt;&lt;br&gt;&lt;br&gt;firewall?  Sometimes with clients Internet Connection Firewall enabled.&lt;br&gt;without logging into?  No.&lt;br&gt;new set of credentials?  Yes.&lt;br&gt;setup on the remote machine?  No.&lt;br&gt;&lt;br&gt;A &amp;quot;Connect As..&amp;quot; credential dialog would be helpful when different credentials are needed to debug a remote system.&lt;br&gt;&lt;br&gt;It would also be helpful if all of the necessary debug DLLs be available in the tailor-made remote debugging share either by xcopy of via a environment variable setting (ie. MFC042UD.DLL, etc).&lt;br&gt;&lt;br&gt;It would also be helpful to define how MSVSMON can be used without disabling Internet Connection Firewall.&lt;br&gt;&lt;br&gt;When debugging native with no auth, it would also be helpful to publish the default ports that are used for MSVSMON so Internet Connection Firewall can still be enabled and the ports can be manually entered.  And\or have an easy way to specify what port the client debugger should connect to when using /port.&lt;br&gt;&lt;br&gt;Thanks for the discuss opportunity,&lt;br&gt;Mark.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=181161" width="1" height="1"&gt;</description></item><item><title>re: What are your remote debugging scenarios?</title><link>http://blogs.msdn.com/b/greggm/archive/2004/06/22/162546.aspx#177748</link><pubDate>Thu, 08 Jul 2004 21:52:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:177748</guid><dc:creator>Gregg Miskelly</dc:creator><description>No, we have made many big changes between VS 2003 and VS 2005. That said, you could go the other way quite easily. You could use 2005 as your main debugger and debug the code that 2003 is producing without installing the remote debugging components from 2005 - just run them from a share.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=177748" width="1" height="1"&gt;</description></item><item><title>re: What are your remote debugging scenarios?</title><link>http://blogs.msdn.com/b/greggm/archive/2004/06/22/162546.aspx#177655</link><pubDate>Thu, 08 Jul 2004 20:21:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:177655</guid><dc:creator>IgorF</dc:creator><description>Firewall: no&lt;br&gt;Without logging in: no&lt;br&gt;New credentials: sometimes&lt;br&gt;Setup: absolutely not!&lt;br&gt;&lt;br&gt;&lt;br&gt;Now, what would be really nice :) is if I could remote debug (both native and managed) from VS.NET2003 on my main dev machine to the Whidbey beta I have installed on a virtual PC running a different OS. Is there any way to make this work without installing/running the 2003 remote pieces?&lt;br&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=177655" width="1" height="1"&gt;</description></item><item><title>re: What are your remote debugging scenarios?</title><link>http://blogs.msdn.com/b/greggm/archive/2004/06/22/162546.aspx#164840</link><pubDate>Thu, 24 Jun 2004 16:09:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:164840</guid><dc:creator>Gregg Miskelly</dc:creator><description>Yes.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=164840" width="1" height="1"&gt;</description></item><item><title>re: What are your remote debugging scenarios?</title><link>http://blogs.msdn.com/b/greggm/archive/2004/06/22/162546.aspx#164550</link><pubDate>Thu, 24 Jun 2004 09:56:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:164550</guid><dc:creator>Staffan Gustafsson</dc:creator><description>What about cross plattform debugging?&lt;br&gt;&lt;br&gt;Compiling for IA64 (on x86 dev machine) and debugging on an IA64...&lt;br&gt;&lt;br&gt;Is that possible with 2005?&lt;br&gt;&lt;br&gt;/Staffan&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=164550" width="1" height="1"&gt;</description></item><item><title>re: What are your remote debugging scenarios?</title><link>http://blogs.msdn.com/b/greggm/archive/2004/06/22/162546.aspx#164150</link><pubDate>Wed, 23 Jun 2004 23:54:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:164150</guid><dc:creator>David Pickett</dc:creator><description>Firewall?  Rarely (but not never).&lt;br&gt;Without logging in?  Yes.&lt;br&gt;New credentials?  Yes, often.&lt;br&gt;Rather run a setup?  No, not if it's avoidable.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=164150" width="1" height="1"&gt;</description></item><item><title>re: What are your remote debugging scenarios?</title><link>http://blogs.msdn.com/b/greggm/archive/2004/06/22/162546.aspx#162621</link><pubDate>Tue, 22 Jun 2004 17:44:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:162621</guid><dc:creator>Roger Lipscombe</dc:creator><description>Firewall: no&lt;br&gt;Without logging in: rarely&lt;br&gt;New credentials: no&lt;br&gt;Setup: definitely not.  Usually the remote machine is a test box that we're trying to keep completely unsullied.  It's better to run a single app, so we know that the setup didn't install any extras/prerequisites that suddenly make our app work -- thus causing a heisenbug.&lt;br&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=162621" width="1" height="1"&gt;</description></item></channel></rss>