I have a SQL Server 2008 R2 CLR Database project with a table value function. The table value function runs select queries in order to preform it's logic. I want to debug this in VS 2010 so I can step through my code but for the life of me I can't figure out how to do it and I have read countless Blogs.
I have a test.sql file and I have set it as my default test script with a breakpoint in my CLR function. When I click the "Start Debugging" button from within my test script VS 2010 will go into not responding mode while it re-deploys my assembly and then after a few minutes VS 2010 will stop debugging with a message that it exited with code "0". It's like it never runs my code.
I have also tried selecting the function from the server explorer and clicking the "step into" option on the context menu but I just get an error that remote debugging is not setup on our development server. Do I need remote debugging enabled and if so how do I go about doing it the right way to get this to work. I have been at this for days and I am ready to pull my hair out. I even spent my weekend working on this. Please any help would be appreciated.
I downloaded http://www.microsoft.com/en-us/download/details.aspx?id=475 the Visaul Studio 2010 remote debugger from here. I ran the .exe to install on my local machine and the development server. After which I was able to use the "step into" feature under server explorer and step through my code.
Related
I'd like to debug Classic ASP website at Visual Studio 2012 with IIS Express. Hence, I attached the iisexpress.exe in VS 2012, but it shows Application Debugging is disabled. What could be a problem ? Do I want to enable any configuration settings?
First of all you need to enable server side debugging of classic ASP script. Do this by running the following commands:
"C:\Program Files (x86)\IIS Express\appcmd.exe" set config "[YOUR_SITE_NAME]" -section:system.webServer/asp /appAllowClientDebug:"True" /appAllowDebugging:"True" /commit:apphost
Where [YOUR_SITE_NAME] is the name of your website. You can find this name by opening up:
%USERPROFILE%\Documents\IISExpress\config\applicationhost.config
...and searching for your site.
Next, start an IIS Express instance from the command line:
"C:\Program Files (x86)\IIS Express\iisexpress.exe" /config:c:\users\kevin\Documents\IISExpress\config\applicationhost.config /site:"[YOUR_SITE_NAME]" /apppool:"Clr2IntegratedAppPool"
Again, [YOUR_SITE_NAME] is the name of your IIS Express website.
Then attach Visual Studio 2012's debugger and set a breakpoint in the script you wish to debug. Browse to your site/script and your should see the breakpoint light up:
Go to IIS-->ASP-->Debugging properties -->enable client and server side debugging
then attach w3wp process from VS2012
I don't have visual studio 2012 to test it on as far as I know visual studio cannot debug asp classic code natively.
The way I debug my asp classic code is to put in stop statements on the line above the one I want to debug
like this post says. the break point is just typing in stop.
function DoDate(inp)
stop
if isnull(inp) then
DoDate = "Never"
exit function
end if
In the above example the page when loaded will stop at the breakpoint and pop up a dialog asking if you would like to debug it, you can then step through the function and even see variables like you normally would.
note: The link says visual studio 2005 but it also works in 2010(and should also work in 2012), you also do not need the DEBUG extension.
also ensure you have server side debugging activated in IIS or this will not work.
I like using Full-blown IIS on my dev machine as it's what my web servers run and have had problems with differences between Casini and IIS in the past..
Anyway, I was unable to do it the way that #Kev suggested. I did some more playing around + reading and found that on the "Attach To Process" window, you need to specifically select "Script Code" in the "Attach To:" option.
1) F9 to set breakpoints in code
2) Ctrl-Alt-P to attach to process
3) Next to "Attach To:" click on the "Select" button
4) Select "Script Code"
5) In my case, attach to "w3wp.exe"
Enjoy debugging your code.
I have a classic ASP website deployed over IIS.
I am opening that website from the same location in visual studio 2010 (in order to debug, as per the steps mentioned here
The problem is that, when I hit F5 in visual studio it is giving me an error saying "your server does not support debugging of asp net or atl..."
I am able to browse the site from IIS, but I want to open it in Visual Studio in order to debug it.
What could be the possible reason and solution of this issue?
F5 doesn't do anything good for classic ASP sites (f5 will try to compile a .NET site and then access it).
I will assume that you are trying to debug the site on the same machine where it's running. The way you debug "classic" ASP using Visual Studio.NET is by attaching to the process running the site. The easiest way to do this is to use the Just In Time (JIT) feature: insert a stop statement in the code (debugger in jscript) - hitting that line should initiate a server-side "Error of type "Script Debugging" was encountered. Do you want to debug?" dialog, with suggestions of available debuggers to use.
Try this and report what happens - there might be some extra steps needed to configure that machine.
Are you using IIS 7?
If so you should the server option "Enable server side debugging"... It should be in the properties window of the site, using IIS Management Console.
Once you do that, when you run the server through Visual Studio, it should open another solution on debugging mode with the relevant code.
I'm trying to debug a CLR based StoredProcedure in Visual Studio 2012 RTM. I have a Sql Database Project. When I try to debug my script file using RightClick -> Execute with debugger it pop ups a warning about harmfulness of attaching a process and when I accept it just say that :
Unable to debug .Net Code. Could not attach to SQL Server process on
'Devserver'.
I've done many different things :
I've added my domain user to sysadmin SQL Server Role.
I've run MSVSMON.EXE on the Remote Server and set up it's permissions.
I've configured Visual Studio Project's ConnectionString in Properties pane.
I've added current domain user to Local Administrators of the Remote Server.
In Sql Server Object Explorer in Visual Studio I've selected the current connection and ticked 'Allow SQL\CLR Debugging'
...
But it still says it cannot attach the process and there is not Source Code that can be debugged.
Do You have any idea ? what do I forget ?
thanks in advance
Hi after a long time searching over internet, Your Question has Given me Answer of Our Question.
Please understand following very carefully,
Start Visual Studio 2012 with Elevated permissions of Administrator
Create SQL Server Project
In Project Settings/Debug Pane, Provide Connection String for Database Connection
From View Menu, Open SQL Server Object Explorer, If your connection string provided in Project doesn't create Instance of Server, then Recreate connection here...
Right click on Instance and Select Allow SQL CLR Debugging, it will show some warning accept everything but read warnings carefully.
Save Project and perform Rebuild, and test a Publish of project by Generated Publish Script.
Now Create a non-deployment script in project, put a break point press ALT+F5 to execute script with Debug option, when clr-procedure will occur and try to go inside it, it will ask for process to attach with windows, Please allow to Attach
above step worked for me, and here a screen shot of it;
"http://i.stack.imgur.com/GQwlt.png"
For more information you can also contact me on;
Vinod W. B. # vinodwb#live.com
Tearing my hair out in despair now after hours of fighting and googling. I'm trying to debug a simple CLR method. Setup: Visual Studio 2010, SQL Server 2008 R2 Express, Vista Business SP2. I'm a domain user but a local admin on the machine, and a sysadmin on the local instance of SQL Server. I created a new VS database project, pointed it to my db connection string (used this db before), then it asked me if I want to enable debuggig for the connection, to which I answered yes.
I verified that the project deploys fine (can see the assembly and its procedure appear in SQL Server Management Studio), and that I can call it just fine within SSMS. I then added the very same EXEC code to the Test.sql script in my db project, and marked it as the default debug script. I then set a breakpoint both in Test.sql and CLR code.
But when I hit F5 all I get is the following output:
Canceled by user.
Auto-attach to process '[2144] sqlservr.exe' on machine 'DAWID-PC' succeeded.
The thread 'dawid-pc\sqlexpress [54]' (0x13c4) has exited with code 0 (0x0).
The thread 'dawid-pc\sqlexpress [54]' (0x13c4) has exited with code 0 (0x0).
The thread 'dawid-pc\sqlexpress [56]' (0x109c) has exited with code 0 (0x0).
The thread 'dawid-pc\sqlexpress [56]' (0x109c) has exited with code 0 (0x0).
The program '[2144] sqlservr.exe: dawid-pc\sqlexpress' has exited with code 0 (0x0).
And my debugging session ends right there.
I have c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe running; I can see a message saying MyDomain\MyUsername connected. appear every time I hit F5 in Visual Studio. I don't have a firewall running on my PC, and have no anti virus software installed.
Do you have any idea how to make it work? My real target was remote debugging but I thought I should try local first and iron out any setup quirks before venturing any further...
I had this same problem. It appears to be an issue with your project being configured for .NET 3/3.5. As soon as I changed my platform to .NET 2.0 I could hit my break points. I can't wait until the have .NET 4 integration in SQL Server CLR types.
I came across this error recently using VS2010 and SQL 2008 R2 (both installed locally). I switched off my firewall, etc. and still have no luck. Eventually I stumbled across what looked like a SQL Server memory issue. The SQL Log Files were showing a lot of AppDomain X unloaded messages. Anyway, the led me to here: http://www.johnsansom.com/sql-server-memory-configuration-determining-memtoleave-settings/#axzz1SZM5nqyF
and after changing my SQL Server -g startup option to -g384, hey presto the debugging worked !!
I'm not a SQL DBA so maybe someone can jump in and add to this if they have any knowledge of MemToLeave settings.
Ciaran
in server explorer remove Allow SQL Server debugging, but set Application debugging
Start debugging and VS will request to set Allow SQL Server debugging.
Then it will work.
Abbas Shojaee
Set your break-points in the source..,Build and deploy (Sql server projects will build and deploy when you run, but will not hit any break points you have set!.)
On the Server explorer make sure you have enabled Application Debugging and Allow SQL/CLR Debugging.
On the Server Explorer navigate to the clr stored procedure/function that you want to debug,
Right click and Step Into (Alt+F5) .. After 'Attach security warning' , you will see assemblies being loaded in the output window , followed by this, break point will be hit and you can continue usual debugging tasks.
I'm trying to build a setup project in Visual Studio 2005, and it is failing every time, after opening a dialog box labeled Microsoft SQL Server 2005 Tools and configuring for a few minutes. The Microsoft SQL Server 2005 Tools dialog then launches a dialog with the text Failure creating local group SQLServer2005NotificationServices$COMPUTER_NAME. I suspect this failure is because I'm not currently local admin on my machine (a situation I hope will be rectified rapidly), but I don't see why I need to configure MS SQL 2005, as my project does not use it, and in fact has no DB connectivity. How can I get past this step to a successful build?
Related:
Visual studio configures SQL 2008 on every build
Visual Studio Setup and Deployment build fails with no errors
Update: Got my admin back, but this is still taking up time to run, and I'd still like to be rid of it.
I found something about it on Microsoft Connect. Seems like it's a bug. In the reply they linked to a knowledge base article with some workarounds.