I'm trying to use Visual Studio 2010 Premium's built-in profiling for Azure and am having trouble. What I'm doing seems to follow tutorials but my "Enable Profiling" checkbox is grayed out. I'm using Windows Azure Tools 1.8 (Oct 2012) and VS2010 Premium running on Windows 8 x64 as Admin. I also have RDP enabled. My understanding is that I've satisfied all of the requirements for profiling.
The only way I know to manage these profiles is to right-click on my Cloud project (the one with .csdef and .cscfg files), click "Publish...", and work with the settings in there. Under the "Advanced" tab, the "Enable Profiling" checkbox is grayed out, so I can't even get to the Profiling settings link.
Any idea what the deal is?
I've given up on this for now and am just using dotTrace for remote profiling. I outlined the steps to get this working here on this other SO question. If somebody has an answer specific to the original question, I'm still very interested in that and will gladly transfer the selected answer to that if you post it. Until then, this solution works well enough for me...
Related
I've created a project on VB6 at but when I am opening it on VB8, it shows the following error:
How to fix it?
As listed by GSerg in the comments, this appears to be a known issue documented in Microsoft Knowledge Base article 896292: You receive a "The remote procedure call failed" error message when you upgrade a Visual Basic 6.0 project to Visual Studio .NET 2003 or Visual Studio 2005 on Windows Server 2003 SP1 or on Windows XP SP2
To reproduce the solution here:
Cause
This behavior occurs because the VBU.exe tool has compatibility issues with the Data Execution Prevention (DEP) option.
Note: The VBU.exe tool starts when you upgrade the Visual Basic 6.0 project by using the Visual Basic Upgrade Wizard in the Microsoft Visual Studio .NET IDE.
Workaround
To work around this behavior, add the VBU.exe tool to the DEP exclusion list. To do this, follow these steps:
Click Start, click Control Panel, and then double-click System. The System Properties dialog box appears.
Click the Advanced tab, and then click Settingsunder Performance. The Performance Options dialog box appears.
Click the Data Execution Prevention tab. Verify that the Turn on DEP for all programs and services except those I select option is selected
Note By default, the Turn on DEP for all programs and services except those I select option is selected in Microsoft Windows Server 2003 Service Pack 1 (SP1).
Click Add. Locate and then click to select VBU.exe. Click Open.
In the warning box, click OK. VBU.exe now appears in the DEP program area.
Click Apply, and then click
OK. A dialog box appears that states that you must restart the computer for the setting to take effect. Click OK.
Try do divide your project to small projects(or comment large part of your project) a try again in each small project.
The idea is to find the function that is production the error.
My intuition is telling me that maybe is a DLL or OCX problem. Try to see all the external DLL or OCX calls and remove from the original project and try again the upgrading.
Most developers who move their VB6 projects to .Net do not even try to port them over. Even with third-party "conversion" software, the effort can be incredibly tedious. So much so, that most developers simply re-write the application completely. Consider it a move to a different language. In fact, some developers use that opportunity to port it to C# instead. I'm a die-hard VB6 user/fan but were I to attempt to port my 200 form accounting application, I'd just re-write it in C#. I started porting it, tried third-party conversion apps, just wasn't worth it.
When I run my Web API application I get the following window:
It just stays like that indefinantly, until I hit cancel.
When I do hit cancel, this error message is shown:
I have tried rebooting, and running iisreset /restart but it does not fix it.
Any ideas what I can do to get my debugger working again?
NOTE: My Web API 2 project's Servers setting is set to Local IIS. My service is hosted by IIS and when I am not debugging, it works fine.
A possible fix:
Check the "Enable Just My Code" in Tools->Options->Debug
I just did a reset for all the settings for VS and it worked again.
Tools => Import and Export Settings => Reset All Settings
good luck!
I had this issue for Visual Studio 2017 and like with the previous post I had Debugging option "Enable .NET Framework source stepping" ticked. Un-ticking fixed the issue.
So as I commented before I had this same issue, but I now figured out the cause and have a solution.
I just got a new machine last week (this issue was actually one of the reasons why) and after a while I had the same issues, not being able to debug my projects. Luckily because I was installing all the updates one by one I was able to pin-point when it started happening.
It seems the latest update for the "Microsoft ASP.NET and Web Tools" extension breaks something.
Sadly, uninstalling or reverting the Web Tools extension is not easy: Remove this extension by going to the Windows control panel and modifying your Visual Studio installation. I had to remove Visual Studio completely and reinstall it (repair didn't do the trick).
You can update and install all your extensions as you wish, just make sure that you don't update the Web Tools extension
I tested this on my old machine and it did the trick there as well.
I've also created an Issue on GitHub as I won't be updating the extension until this is fixed, if anybody has additional information please add it to the Issue.
In Visual Studio 2015, go to Tools -> Options -> Debugging and deselect "Enable .NET Framework source stepping". This may relate to an issue with loading symbols, so if you want to keep the ability to debug .NET Framework source, then it may help to search the web for how to clear the symbol cache, or preload it, or set your symbol server, and so on.
In Visual Studio 2017, I just restarted my machine and ran the solution, no other windows opened not even a browser, although visual studio took a long time to open (30+ projects in a solution) the problem did not reoccur.
I had the same issue in VS 2017 and un-checking 'Native code' did the trick. Not sure why it was checked.
In my case I set Debugging ->Symbols -> To "Load Only Specified Modules" to include the symbols for, in my case a devops symbols feed for some internal NuGet packages
Options>Debugging>Symbols>Load Only Specified Modules
By checking the option "Always load symbols where located next to modules" the setting won't mess with the regular/classic debugging in VS for your own code
This way the Symbols are still loading where needed and Visual Studio is not trying to load debugging information for all the IIS .net dlls that were loaded by w3wp
Alternatively it can also be configured to not load symbols for microsoft.*.dll and it will also work.
Didn't see this in the current answers, so thought I'd give my 2 cents in 2022:
What worked for me:
Make sure to check that your IIS application pool hasn't been stopped (and restart it if it is), and then if that's not the case, restart your IIS server.
If you don't where those settings are, open our Internet Information Services (IIS) Manager, Application Pools are in the left-hand column, and restart/start/stop your server is in the right column.
I installed Microsoft Visual Studio and during installation i think i somehow ticked the Team Project checkbox. Now i'm unable to create a normal ASP.NET website in any way. I would be very grateful if someone tells how to fix this thing. Also i have uninstalled and installed seven times. But no luck. Thank you.
If I have understood You right. You try to change default templates in IDE for Web developers.
In Visual studio you can easily change the profile of the IDE by going to Tools -> Import Export Settings. This brings up Import Export Windows Wizard. Follow the simple Wizard (which also allows to save you the current settings for future use) and select the new profile setting (based on the kind of project you are working on) and you are ready to work with new profile.
I assume You need to choose "Web development".
I've searched high and low for the answer to this and can find nothing on it. I have installed VS 2010 pro edition on a virtual machine running MS XP Pro. After connecting to my database, I can see all the tables, stored procedures, and functions just fine in the list. However, when I rick-click on any of them, the options to create new/edit/run any of them are missing.
This is not the first time I've set up VS 2010. I got a new laptop so reinstalled everything. I changed no settings the first time I've set this up, and none this time. I set up the connection to the databases the same way each time, and even looked at my old connection settings while I set up this installation. The old installation had all of the right-click options, but this one does not. I have tried going to Tools -> Import and Export Settings -> Reset all settings and tried General Development Settings, Visual C# Development Settings, and Web Development as the default collection of settings. None of these worked.
I've looked through the settings and found nothing for the right-click menu. It almost seems as if the database connection is open in a "read only" mode, but there doesn't seem to be a setting for that, so I don't think that is the case. If anyone knows of any way to get these options to show up, I would greatly appreciate the input. Thanks in advance.
After I installed Visual Studio 2010 (Ultimate), I accidentally uninstalled the SQL Server Data Tools which were installed together with VS, and after reinstalling them (by repairing the VS installation) the missing context menue options were back again.
Desperate to resolve this, I played around with the connection more. I had originally chosen Microsoft SQL Server as the data source, and .NET Framework Data Provider for OLE DB as the Data Provider. Evidently, the data provider was wrong. After choosing .NET Framework Data Provider for SQL Server, it worked and I could see all of my right-click menu options.
I have VS 2013 Ultimate installation. Along this version I installed SSTD BI. Everything was working perfect until I got the same issue. Right-click on tables or other folders displays only three options: copy, refresh, property. The tricky thing is that it's impossible to uninstall SSTD BI in Control Panel or install SSTD BI on top of previous installation. What helped me is repair installation of VS2013. Start your installation file and chose repair instead of installation. Couple hours and it's back to work.
I downloaded SSTD from here and it fixed my missing context menus
https://msdn.microsoft.com/en-us/mt186501
Im using VS express web developer, and attempting to create a new MVC project. The problem is, VS hangs when adding EntityFramework to the project. Its attempting to add EntityFramework 4.1.10331.0 to an MVC 3 project. Any ideas what might be going on?
It has been a while since you asked the question, but I recently stumbled across a similar issue except with MVC4 adding EntityFramework.5.0.0 in Visual Studio 2012 Ultimate.
The issue was that I was trying to create the project in a network folder (I run Windows 7 in a VM on top of OSX).
The problem appears to be that the network folder is not considered a Trusted Location. I had to go into Control Panel -> Internet Options, click "Security" tab, Click "Local Intranet" zone, then click Sites button.
In the "Local intranet" dialog which pops up, I un-checked "Automatically detect intranet network" and checked "Include all network paths (UNCs)"
Now I guess Visual Studio and/or nuGet see the network folder as a trusted location, and EntityFramework.5.0.0 is installed along with everything else a new MVC 4 project requires.
Credit goes to my colleague who referred me to this SuperUser post.
Bit of an old question, but it's still an issue today so this might help someone looking for a solution.
I don't have enough rep to comment on Chris Cameron's answer, so apologies for submitting it as a new answer - all credit should go to Chris. I found that to get it working I also needed to check "Include all local (intranet) sites not listed in other zones." Chris' solution then worked like a charm.