{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 我想做一个坏孩纸 的问题《Are there any drawbacks to running Visual Studio r》','https://www.manongdao.com/q-930614.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
Let's say you have a slow laptop which can't handle Visual Studio but a blazingly fast desktop that can. Let's also say that you want to develop in several rooms in your house. Are there any drawbacks to having Visual Studio running on the desktop and simply using the laptop as a way to access it remotely? I'd guess that the only thing that you would be concerned about would be the network latency, but if the two computers are on the same network that should be minimal.
标签：
visual-studio
相关问题
- How to know full paths to DLL's from .csproj f
- Importing NuGet references through a local project
- Visual Studio 2019 - error MSB8020: The build tool
- 'System.Threading.ThreadAbortException' in
- VS2017 RC - The following error occurred when tryi
相关文章
- How to show location of errors, references to memb
- How to track MongoDB requests from a console appli
- Visual Studio Hangs on Loading UI Library
- How to use Mercurial from Visual Studio 2010?
- Copy different file to output directory for releas
- Edit & Continue doesn't work
- “Csc.exe” exited with code -1073741819
- Visual Studio: Is there an incremental search for
Do it.
Since you are running Visual Studio in your own local network, the main drawbacks (security and latency) are not there. In addition, you get the speed of your desktop and the mobility of your laptop.
No big drawbacks. I've been running VS 2008 remotely on a server 400 miles away, using GNU/Linux and rdesktop on my laptop and the server (of course) running Windows. The only problems I encounter are that it is a mess to move files between the two - but if you have the desktop near and can install anything you like (ftp programs for example), I can't see any drawbacks.
I work a lot with Visual Studio over broadband, which is ok. If you are running linux on your laptop, rdesktop is your friend. There are many options to gain more speed, like using 8-bit color instead of 16 or more. I don't know if mstsc offers such options. Visual Studio 2008 has got many options concerning speed which can be enabled if the connection is too slow: disable fancy menus etc.
greetings
In a corp work environment where I've tried this I never felt particularly joyful. Tried using MSTSC and VNC.
Having a desktop with multiple monitors and trying to view that through a smaller laptop display is typically quite painful, never enough space.
Even when it was PC's on the same switch there always seemed to be some delay in the mouse moving or typing, I'm sure you could adjust, I just found it a bit annoying too.
We haven't tried serving up DevStudio from a CITRIX server yet, that might be worth a go.
I think that having the dual (or more) monitor set-up does beat the ease of mobility when using a laptop connecting to a remote desktop. I work at home at least two days in a working week using my laptop (which is a 17", 1900x1200 screen, basically what they call a "desktop replacement"), connected to VS and TFS using VPN and I find that experience less than the situation at work where I have the 17" laptop screen AND a 24" TFT (also 1900x1200).
I also have experienced that running VS (or SQL Server Management Studio for example) over an RDP session is just not like the real thing. It does get the job done, however the "feel" isn't just the same.
This is my standard working practice at work. There are times when you have issues, such as opening TFS document attachments can fail, but overall the experience is fine.
It is also an added bonus that you can leave it running continually (i.e. overnight / weekends) and you can kick off a build before you leave for the evening and come back to a packaged installer (or an error :) ).
I'm looking forward to (in a year or two) be able to do this over Hyper-V - then the application will run as though it IS on my laptop, with no remote desktop required.