I am trying to create, test and deploy a SQL CLR (database project) using Visual Studio 2012 (update 2) and it is getting very frustrating.
The coding itself was trivial but now I cannot deploy or execute unit tests on the project. I have developed SQL CLR in VS 2010 and it was much simpler (Test.sql).
So here are my questions:
How does one set up a local SQL script to test the newly minted functions/sprocs? [I have tried adding a .sql file and marking it to be run on debug but I get error SQL71006.]
How does one deploy the project? I am deploying to SQL 2008 R2 and I know I need to use .NET 2.0 but I still have not been able to deploy anything. When I execute the generated .SQL on the target SQL Server instance, nothing happens (no errors, nothing).
This has worked so well with previous versions of Visual Studio one wonders if MSFT is perhaps now trying to discourage the generation of SQL CLR modules?
For first point, ensure that .sql file in properties has anything then Build in field Action
For second point, try to use a Publish option, where you will get a dialog box to set up database connection and other config option.
Deploy option does nothing when you work with database projects.
Related
I have written a CLR stored procedure (.NET Framework 4.5 and IDE VS 2019) and trying to debug the CLR stored procedure before deploying it to SQL Server 2016. However, I am unable to locate the debug option for CLR DB object.
I did try steps provided on Microsoft document but unable to find [Test Scripts] folder in Solution Explorer. I am using Visual Studio 2019.
https://learn.microsoft.com/en-us/sql/relational-databases/clr-integration/debugging-clr-database-objects?view=sql-server-2016
What exactly do you mean by:
debug the CLR stored procedure without deploying it on SQL server
? The code only runs in SQL Server. It needs to exist within SQL Server in order to be callable as the environment that calls it is SQL Server. Visual Studio comes with SQL Server Express LocalDB so that you can easily test stuff like this on your local dev box without having to deploy it anywhere outside of your personal dev environment. When you create a database project, the debug connection string (i.e. where it deploys to when publishing to test, whether you start debugging or not) should be preconfigured for your local instance of LocalDB.
Please try the steps I outlined in my answer to "How to debug a CLR Stored procedure in VS 2013". That was tested on VS 2015, and I expect the behavior to be the same in VS 2019. Either way, that answer contains some required steps that are missing from the MS documentation.
I'm new to SQLServer and related Visual Studio tools though I know SQL well.
I want to have a local test DB on my dev PC with some stored procedures (so it needs to be SQL Server not SQLLite). LocalDB seems the answer and I can create a LocalDB MDF file through Server Explorer. But I don't think I can/should be putting an MDF file in version control - other developers need to have this DB for their local testing too.
I feel like the Visual Studio SQL Server Project type is what I'm after here but I don't see how such a project is linked to an actual DB. In my mind I imagine setting up a SQLServer project in VS, adding tables/stored procs/etc, and this will automatically build a LocalDB MDF file.
I'm unsure how thee things hang together and where the files all go, can someone help clarify this?
I'm basically starting from the point: I have a SLN with my C# projects in. My C# code calls certain stored procedures using a connections string from configuration but no DB actually exists in the wild yet. Any developer ideally needs a dummy DB to be created when they build the code, not have to create it manually, without installing SQLServer.
So it seems like I want to create a SQLServer Project in my solution, which will magically create a LocalDB. Is that feasible/correct?
Do you need to use Visual Studio at all, would SSMS not meet the requirements if you only want to execute some stored procedures? SQL Server Express is free, it's just limited on size, I believe that the SQL developers edition is free as of pretty recently, may be worth looking into.
I've got a couple of installations of SQL Server on Hyper-V Virtual machines too for testing purposes, this could be an option.
I have VS 2010 project with SQL Server unit tests. I need to convert them to VS2012. After much googling I found a msdn article which does not lay out the steps. The context menu on project does not contain anything related to project upgrade. After opening the project in 2012 you wont see your test sql unit test queries. If I open it in vs 2010 I see them. After opening the project in vs 2012 and if I create new sql unit test it will get pop-up box saying :
I have SSDTBI_VS21012 installed. Any idea how I go about converting my VS2010 project with SQL Server unit tests to VS2012?
I work on the product team, thanks for raising this. After a quick investigation, this looks like it is a regression introduced in the July release of SQL Server database tooling in Visual Studio. Could you please file a connect bug for this issue at https://connect.microsoft.com/SQLServer/feedback/CreateFeedback.aspx and use the category "Developer Tools(SSDT, BIDS, etc.)". We will treat this as high priority, and this is the best way to ensure it'll get tracked and you can see when it's fixed.
Unfortunately there is no workaround in the July/November releases as an overzealous check was added to avoid showing this option for all unit test projects, and we don't have an overrideable command. However, to unblock yourself you should be able to do one of two things:
Workaround #1 uninstall the database tooling components and install an earlier version instead. Here's how:
Go to Add/Remove Programs
Uninstall "Microsoft SQL Server Data Tools 2012", which is the overall installer, if present
Uninstall "Microsoft SQL Server Data Tools - enu" (if you have English installed).
You shouldn't have to uninstall "Microsoft SQL Server Data Tools Build Utilities - enu" if you're using July/November release as it's no longer relevant. However if you run into trouble, consider uninstalling this too.
Install the April release of SQL Server tooling for VS2012 instead. The SSDTSetup.exe file to do this is found at http://download.microsoft.com/download/0/D/F/0DF6C816-A7D5-4C17-8B10-2061FC97D37E/EN/SSDTSetup.exe. Note if you are not using English, change the "/EN/" part of the URL to a different language such as DEU and it should allow you to download that language version.
Workaround #2 Migrate to a new Unit Test Project
You can alternatively create a new SQL Unit Test Project and migrate your tests across:
Create a unit test project based on a procedure in your SQL Project, or create a new Unit Test Project and go to "Add -> New Item -> SQL Server -> SQL Server Unit Test").
When it opens the SQL Server Test Configuration dialog, be sure to enter valid values for the reference project and the connection string(s) - these should match your previous project
Copy across your unit test files from the old project. If you build, it will fail due to a missing reference. We'll fix that next.
Unload the project (right-click, unload project) and add the following snippet near the top:
<PropertyGroup>
<IncludeSsdtUnitTestAdapter>True</IncludeSsdtUnitTestAdapter>
</PropertyGroup>
Reload the project, and build. This should now pass as the adapter DLL used in migration will be included in the references.
Lastly, run the tests and it should work.
How does one debug a T-SQL stored procedure in a multi-tier application in Visual Studio 2012?
To be clear, I want to set a breakpoint in a sproc in VS 2012, and hit it when the sproc is called from an ASP.NET WebForms app in the same debugging session.
When following the same steps as for VS 2010, the breakpoints aren't hit inside the sproc.
Debugging T-SQL in a sproc on a SQL Server 2008 R2 Express database works as expected in Visual Studio 2010.
To be sure everything was enabled properly, I went over the instructions for VS 2010 (here), but no such page exists for VS 2012 or .NET 4.5.
It seems the missing step is to enable "Application Debugging", but no such option exists in the Server Explorer > Data Connections context menu in VS 2012.
VS 2010 Application Debugging
VS 2012 No Application Debugging
You need to open "SQL Server Object Explorer. Not "Server Explorer". That is what is different between 2010 & 2012. Then right click on the server and select "Application Debugging".
This is for VS2012 and SQL2012. Yes things are somewhat different for other versions, but kinda follow similar setup. It is tricky because one has to have various settings just right or it won't work.
vanilla install of both VS and SQL with all correct options (how to do this is outside scope of this article)
full admin rights to entire environment and sysadmin rights to sql (fundamentally a development environment; you would not want to do this in a production environment)
i always debug .net web apps under full local IIS which is a windows feature installed from control panel
go .net project properties, web, use local iis web server (i also stick to default port 80)
while i develop my databases etc using VS sql server database project, i always work under full standalone local SQL; i use the schema compare to refresh that sql with changes made in VS (how to do this is outside scope of this article)
do not place your breakpoint on that copy of the sp; that version of the sp is only a blueprint and not the runtime version
go .net project properties, web, debuggers (at bottom) enabled for .net and sql server
view sql server object explorer (not server explorer)
click add sql server, add your full local sql server using sysadmin credentials (i always use sa for such work)
right click on your full local sql server and enable application debugging
there go find the sp and right click and view code, then add your breakpoint there; this is runtime version of sp (note that i never make changes to sp there, i go do these in my master copy under the database project)
rebuild solution, and execute .net web app in debug mode from within ide by clicking green arrow internet explorer
I hope I have not forgotten anything. If I have I'll come revised my post.
All this may sound complicated. It is. But with a little discipline and patience it is priceless.
Good luck.
I believe the easiest way to do this would be to add DB as a project to your solution. You can do this by right clicking on the DB in the SQL Server Object Explorer (SSOX). This is a really good way to develop and debug your DB's. After you have added the DB to your project, you can add breakpoints anywhere you want, and debug against LocalDB (or another target if you wish). The largest drawback to this approach is that your existing data will not migrate with you (although you will be able to easily publish any changes back to the SQL DB at will). See the documentation on SSDT on MSDN for further guidance.
The following in detail article explains exactly how to enable debugging of a Stored Procedure when a .Net application is executed.
http://www.sqlmag.com/content1/topic/debugging-stored-procedures-142054/catpath/sql-server
Hey, I've just finished writing a VB.NET application. Now I want to package the executable and the database ofcourse into a single installer file. I tried using QSetup, InstallShield to make SQL Server embedded into the setup file, and finally after hours of try&fail I have no idea. Anyone?
You can do a rightmouse on the properties of your Visual Studio Setup Project, and then there is this button 'Prerequisites'. There you can tick 'SQL Server Express ...' Or the 'SQL Server Compact 3.5'
link to image
You're probably best off just to set the connection file directly to the mdf, and attach it when the program is run. This is easier as it doesn't require a custom setup script to install the database to the database directory itself.
Note: Consider using the Compact Version, it's smaller, people don't like a full blown engine on their computer :)
InstallShield has a concept called Setup Prerequisites where you can teach it how to install additional packages along with your own. In older versions this would happen before calling your MSI. In newer versions you can have a "Feature" prerequisite where the prereq can associated to a feature and only installed if that feature is selected to be installed and after it's been selected but still before the main activity of your MSI occurs during the install execute sequence.
InstallShield also has a pattern for executing SQL scripts against your database instance so that you can then load your database into your newly installed instance.
All of this is quite powerful but it does take a bit of digging to learn.
As far as I know, anything but the SQL Server Compact Edition (SQL Server CE) cannot be embedded into your setup, really. Microsoft doesn't want that - you need to have SQL Server Express installed separately - any other edition can't even be shipped with your software (the client must have a license and installation separately).
You can indeed distribute SQL server with your custom application:
http://msdn.microsoft.com/en-us/library/bb264562(SQL.90).aspx