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.
Related
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.
I have created ATL Services. When I am building it gives message on Visual Studio 2005 on Windows 7 64 bit PC
**1>Linking...
1>Embedding manifest...
1>Performing registration**
one wondow pops up with dialogue " Could not Open Service Manager "
and When I am trying to run my project its giving this error
**First-chance exception at 0x7709c41f in XYZ.exe: 0x00000005: Access is denied.
The thread 'Win32 Thread' (0x1844) has exited with code 1063 (0x427).
The program '[10592] XYZ.exe: Native' has exited with code 1063 (0x427).**
I checked regedit too, nothing is registered in regedit/Appid.
Someone Please help me to understand this problem.
Thanks a lot in advance.
If you want, that VS is able to modify the registry you must start VS "As Administrator...". by Default the UAC prevents the Access to the registry. So right click VS and select "Run as Administrator..."
As far as I remember, ATL version of Visual Studio 2005 is not DEP-safe: it executes thunk code from addresses not specifically allowed to contain executable code. This crashes the application, and you need to either fix thunks on ATL code, or put your application on DEP exception list.
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
I have a very annoying issue with visual studio 2008 sp1 on windows 7 64 bit.
The software we are working on uses a client that connects to a windows service. so, when i do a debug, i debug on 2 processes, the client and the service.
When hitting a breakpoint on the service, and using F10, F11 for 20-30 times aprox, I get an "Visual Studio is busy doing an internal operation ..." message, after which the debugger throws me to another place. If I look at the call stack, there is a message "Evaluation of:". above it, the call stack where I currently am, and below it, there is the call stack where I was before the error occurred.
here is something similar: http://social.msdn.microsoft.com/Forums/en-MY/vsdebug/thread/4c30e3f4-587e-4f14-8cec-8663d268c55c
I tried installing latest updates, cleaning solution, deleting dll files, *ncb, *suo. nothing worked :|
It's not related to the wpf editor bug.
Thanks.
This is barely an answer, but I had the same problem with VS 2008 (updated to KB972221) running on 32-bit Windows XP.
The key seems to be running two instances of VS2008 at the same time.
I had a client/server setup and was running each of these executables via its own VS2008 instance. The server was multi-threaded, the client I think single-threaded.
Like you, I had set a breakpoint and was then F10 stepping through the code when I had the same experience of VS hanging for a while then dumping me elsewhere in the code following an Evaluation of: message in the call stack.
However, I changed to simply running the client executable on its own, with just the server running in debug mode with VS2008, and the problem never recurred (to date!).
So maybe the workaround is simply to stick to a single VS2008 session.
I've recently put Windows 7 on my development PC, and I have Visual Studio 2008 Team System Development Edition, and SQL Server Management Studio 2008, and for some reason I can't seem to step in to any SQL code for debugging in SSMS.
Before I formatted in favour of Windows 7, I was able to debug on the same two SQL servers I'm trying now with the same software, so I'm guessing it's something to do with client configurations. Regardless, I tried all the steps I could find to enable SQL remote debugging but nothing has worked.
When I attempt to debug or step into the active query window, the debugger simply runs the code without stopping at the start or any breakpoints.
If I try use Visual Studio (running as Administrator) I get the following error:
T-SQL execution ended without
debugging. You may not have sufficient
permissions to debug.
Anyone got a clue what to do here?
EDIT
I'm still having this problem. I re-installed the latest SQL Server Management Studio from MSDN's latest SQL Server 2008 download available, and patched it with SP1, but this same problem still happens. Other people in my office are able to debug code with the same version client, and same permissions (set using group permissions) so I'm at a loss as to what is causing this.
FINAL EDIT
Solved! The issue was simply a domain authentication issue. See my answer for a larger explanation.
Have you made sure that in Server Explorer (In Visual Studio), if you right click on your connection that you have "Allow SQL/CLR Debugging" and "Application Debugging" checked?
Today, I finally solved this.
I was writing an ASP.NET application that included the line:
User.IsInRole("DOMAIN\\Administrators");
And this was throwing the following exception:
The trust relationship between this
workstation and the primary domain
failed
I wasted a little time applying the KB976494 hotfix, which I soon discovered didn't work. During my developer rage I looked in my local "Administrators" account and noticed it listed almost all members by their S-ID, so figured there may have been a domain problem.
Then it came to me... I remembered I joined the domain with my personal (non-administrator) account, instead of using the domain administrator account.
These were the ultimate steps to fix this issue:
Leave your domain (and join an arbitrary workgroup, such as "WORK")
Reboot.
Join your domain with your "DOMAIN\Administrator" account
User.IsInRole() now worked, so out of curiosity I checked this problem, and it was also fixed.
This is a great Friday so far!