As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've noticed Visual Studio 2010 is a lot slower than my Visual Studio 2008 IDE, I've found several nice tips and optimization suggestions for VS2008, however I want to know if people have any tips for VS2010
Two parts to the answer:
First, I'd really appreciate if you could download this diagnostic tool to take traces. It isn't a fix, but it'll help us improve the product. If you send me an email (noahric at msft), I can send you instructions and find a place for you to upload these traces. Same goes for anyone else reading this question/answer; the more traces, the merrier.
Other than that, there are a few things you can try:
In Tools->Options->Environment->General, turn off "Automatically adjust visual experience based on client performance", and turn off the rich client visual experience.
You can also try turning off hardware graphics acceleration (from the same location). I've found plenty of cases where the performance is better with software rendering.
If you are working with really large solutions, try the solution load manager. It lets you disable auto-loading of projects within a solution.
Do you have any extensions installed? If you do, you can try disabling them.
Run fewer instances of VS at once. I personally run quite a few at a time, but I've heard plenty of reports where people run enough instances of VS to exhaust virtual memory.
I hate to be a contrarian, but I just turned ON "Automatically adjust visual experience based on client performance" and VS2010 Ultimate is now almost as fast as VS2008.
I previously had that setting clear and had "Use Hardware Graphics Acceleration if available" checked.
I've been seriously contemplating going back to 2008 because of the awful performance of 2010.
I have a Precision Workstation with:
Quad-Core Xeon # 3.40GHz
16Gig RAM
3x15K 300 Gig SAS drives
NVIDIA Quadro FX 1700
Running Server 2008 Standard SP2
The machine is not underpowered, and if I open a very large solution with VS2008 (it's also installed), with multiple instances of VS2010 open, it opens almost instantly.
I'm starting to think there is an incompatibility issue with the FX 1700 in VS2010.
Maybe this problem is very config. dependent.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Could you please recommend me a good application level debugger for Windows 7 x64? It is not needed to debug 64-bit applications; it must only run reliably within a 64-bit environment.
I am searching for something like OllyDbg (http://www.ollydbg.de/). However, the problem with OllyDbg is that it is not yet ported for Windows 7 x64.
This has been tried:
SoftICE (does not work for Win7 x64)
Syser (it was giving me error messages after installation)
WinDBG (this one looked too complex and slow to learn. I did not like floating windows all around)
IDA pro (this one did not allow me to debug application. It only listed the structure graph)
OllyDBG (after loading the application, it terminates it immediately. Probably a result of compatibility. I also checked emulating Windows XP SP3, but not help at all)
It is required to run the application in real time, and trace it in assembly language.
Both OllyDbg 1.10 and IDA pro works fine in Win7 x64.
For OllyDbg use Stealth64 plugin.
Visual Studio is decent as a program-binary debugger, it's excellent for programs with .pdb information and source code. Only the advanced version of IdaPro works on 64-bit OS's. From their website:
IDA Pro Standard supports the following families (64-bit analysis is possible only with the Advanced Edition)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am going to start developing GUI applications with QT on a Windows platform. I have Visual Studio 2008.
I would like some suggestions as to just go with the QT IDE and do everything there or just install the QT plugin for Visual Studio and keep using Visual Studio as my IDE tool.
Are there any differences or benefits?
Thanks!
If you're very experienced with Visual Studio then it's probably best to just stick with that. But the Qt IDE does have a lot of nice stuff specifically designed for working with Qt, so that would be my preference.
I have never worked on a QT project with VS. Although I use VS for c# development.
But I have used QT creator (QT IDE) : it's fast (lighter than VS) and powerful tool except debugger VS is winner. From LGPL license and multi platform it integrates all QT supports (docs, help, nav ...) and GUI editor mode works perfectly.
I don't think you can find better in VS plugin.
Moreover QT creator interface is really simple and intuitive. You will not need to spend lots of time to assimilate it.
See Qt: Should I use Visual Studio, Qt Creator or something else?
See Which is better? Qt Creator or Visual Studio IDE
See Visual Studio or Eclipse - which one is better for Qt on Windows?
If you can go with a slow debugger but fast & very nice IDE, then go with the Qt Creator. If you learn all the quick hotkeys (not much of them) then you'll find that you're barely using the mouse any more. I like this feature very much. You can open any file, any method or going to anywhere in your project with only keyboard very easily. Your development will be much accelerated.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
Regarding to this post, can visual studio 2010 RC ready for production
I know there is already a duplicate question here, but that was asked when beta were available.
RC is release candidate... means if no major crashers are reported this will be the build that would go out for production. Thus, you may use it at your own risk. But, per Microsoft, do NOT use it for production.
I work for a .NET component vendor (Syncfusion, Inc). We work for long cycles on pre-release code and have been very happy with Visual Studio 2010 RC. We had no trouble moving our code over. IDE integration features worked perfectly. It is a sweet upgrade especially if you are working with WPF, Silverlight or ASP.NET MVC. I would certainly say that Visual Studio 2010 RC is ready for prime time.
I wouldn't start building a mission critical application using .NET 4.0 just yet. I'd use it to see some of the new features and get comfortable with it [as microsoft always love to move things around].
This is an entirely new runtime they've built, so it's a much bigger chance than 2.0 to 3.5.
So, basically, don't bet your career on it just yet but definitely use it.
I've been using VS2010 pre-RC for a few months working on a fairly demanding WPF application. It's ready, and it's awesome; I don't even have VS2008 installed on my machine anymore.
As of the Release Candidate, anyone running Windows XP Service Pack 2 is now locked out of Visual Studio 2010. I cannot upgrade this work computer to SP3 which is a huge pain in the ass as now I cannot use VS2010 unless Microsoft circumvents this dependency on SP3 via a patch.
Many big corporations upgrade their systems very, very slowly and thus Microsoft has locked out a lot of people not able to run SP3 from using it.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
For a very small side project, I need VS professional. Since the target is .net compact framework, the Express edition won't do (neither will Standard edition). But the price of VS professional exceeds the reasonable price for that project. (Basically, it's just a form with two text entry fields and a button, that creates a text file with the data entered).
Is there an application service provider that lets me use Visual Studio through RDP and charges per hour/day/month?
I've never used the program in anger, but I think that SharpDevelop will produce compact framework applications. You may find that it is feature rich enough for the simple application that you want to write.
AFAIK, the regular licence for VS is for the user, not the install. So if this is available (and I've not heard of it myself), it would be under a different license.
How large is the work? Could you get it done during a trial license? Hopefully that will be enough to convince you to buy a copy (or even an MSDN subscription) for long-term use.
Remember: Visual Studio is just the IDE. You can always use the available SDK and another editor. VS isn't the only .NET tool out there.
If it's not commerical but only for education, just download it from somewhere. Rent model would be stupid, while you contemplating and staring at the screen, there will be counter ticking your $$$$.
I am not sure if VS Prof offers trial period or not. You can try to finish up your project before trial period expired.
Related to Marc's suggestion of a trail version, currently there's also a beta of Visual Studio 2010, perhaps you can make it work for you. I haven't tested it, but it should be compatible with older versions of .net.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Currently thinking about pitching the argument for us migration from vs 2005 (winforms) to vs 2008 (wpf). My main point being the new UI design features.
I am slightly worried that we will put loads of work into upgrading everything only for us to have to do the same when 2010 comes along? So this leads to also consider skipping 2008 and just adopting 2010 as soon as its released.
Anyone been in the similar situation?
Also any arguments for and against for welcomed.
Cheers.
Personally I think it will be fairly safe to go to 2008 as 2010 is just extensions on top of it and enhancements for Visual Studio design time support for WPF. Therefore, the transition shouldn't be all that complicated. More like a 2005-2008 upgrade of a Win Forms or ASP.NET project, which is a cakewalk.
I find that it is better to upgrade sooner than later, so that you don't get "bogged down" with the existing framework/system. If you continue building on something that you will ultimately replace, it becomes harder and harder to justify to management to move.
I was in the same situation and opted to go down the MSDN subscription route, where I get all the new development tools as they come out. I have a spare machine the I use for 'the next version' of the compiler, that I use for migration testing, thus I at least know what to expect when the decision has to be made. This works well for me, and I guess if you have a decent virtualisation set-up all the better.
New compiler versions didn't break my build, but did hurt many of my automated tests, and add-in productivity tools. Basically. you need regression tests of some kind to ascertain the damage moving to a new version is likely to cause.
Your question doesn't quite make sense to me. Are you asking if you should migrate existing applications from Winforms to WPF? Or do you just want to start making new WPF applications but still work with existing Winform projects?
Either way, migrating from Visual Studio 2005 to 2008 is extremely simple. Existing Winform projects request a conversion which takes a few seconds and has never failed for me (dozens of solutions and 100s of projects converted over the last couple months).
However, this has nothing to do with Winforms and WPF.
If you want to start building WPF apps there is no reason to wait for VS 2010. VS 2008 has excellent support for both application types.
I agree with those suggesting adopting VS 2008 now. One thing to consider though is that WPF comes with a fairly high learning curve. I've had some limited exposure to WPF and Silverlight and am finding them to be a complete "mind change" from the WinForms model. Good luck.
I'd make the jump now if I was in your shoes. It'll minimize the impact of the 2010 jump down the line by getting you used to the many new features you'll already have to get used to. Additionally you'll get to enjoy many months of better performance and features before 2010 is available.
Winforms vs WPF is a world of difference. It's a much bigger change than looking at migrating from 2005 to 2008. I would not have that as the driving reason to upgrade to 2008. I also have no idea of the scope of your project and if WPF is really the best direction to take your product. Or if expression blend is all the tooling you need to get these UIs going.
Instead of pitching the WPF pitch I would focus on the real benefits you can get immediately. With 2008 you have multi-targeting so you can build all the applications you used to build in 2005 and have them target the 2.0 framework. In my experience I find 2008 faster and the refactoring improvements are a great addition. There are a ton of other new improvements in 2008 which you get out-of-the-box and can start using from day 1.
According to Rico the head architect of 2010 you will get even richer multi-targetting with 2010 which will allow you to adopt 2010 earlier and not force you to use CLR version 4 from get go.
At the moment I've made it a practice to upgrade to the latest version as soon as possible. Although for an application developer it's got its own pitfalls, Ex. .Net Framework 3.5 is not found on most computers, and if I ship the bootstrap installer which is 20 MB it insists on an active Internet connection to download the files needed. The full installer is 198 MBs and though I don't like it, I have to ship it along with the software.
For a web developer though the problem is easier to solve, you only have to worry about making it work at the server and things work automatically for the users. So if you're making a web solution I think Migration is easier.
If you're making an application software, I think you should weigh the advantages that migration offers with the changes it will make to your deployment scheme. I don't know how many people will agree with this, but I believe that application developers should be one upgrade behind.
There is an underlying process question here that I think shouldn't be overlooked:
When is the proper time to upgrade development tools and production environments?
On the one hand you could skip 2008 though this leads to the question of when would 2010 be adopted: Upon first release, first service pack release, or some other milestone? This may lead to creating more legacy code if you stay locked in on 2005 using the 2.0 framework and others move onto other frameworks. Even if you switch to 2008, it can still target the 2.0 framework so that that upgrade of the .Net framework may happen separately which some may like. Another key point in this camp is who does the research to evaluate the differences between versions to see which is worth the shift.
On the other, you could suggest that there be a continuous strategy of preparing to upgrade every 3 years or so as the Visual Studio releases of the past decade were roughly 2002, 2003, 2005 and 2008 so far. This would seem to me to be the better approach as there is more of a constant evolution going on rather than staying locked in at all. In this case there may be new features that get used since the new tools come quickly compared to the first case where the shift may be viewed as a large step whereas in this case it isn't that big since you are always looking to move in 2-3 years.
Course as I say this my old work machine has Visual Studio 2003, 2005 and 2008, so I am kind of in that latter camp which makes sense to me. I remember 10 years ago my work machine had NT 4.0, Pentium II 333 MHz processor, 64 MB of RAM and a 4 GB hard drive that had to be 2 partitions as it wouldn't let one partition be that big. Now my work machine has 4 GB of RAM alone, a 2.66 GHz dual core processor and a 160 GB hard drive. Could I in another 10 years have a machine with hundreds of GBs of RAM? While that may seem ridiculous, if I were sharing a machine with a handful of other developers, it may make sense to divide up a huge amount of memory amongst us all.