I'm running some load tests using Visual Studio 2010. I haven't been able to figure out how to set where the test results are saved, and it seems that I have no test results to browse once the test runs.
I have the general idea that you're supposed to supply a SQL connection string specifying a SQL server with some tables set up on it.
Where do I set the connection string for local test runs? Is it possible to configure VS2k10 to save my test results to a file locally?
Please note that local SQL databases such as SQL Express are specifically forbidden in my environment.
If you find yourself in a situation where you didn't setup the database to store the test results from the VS 2010 Load Tester, the following will help.
The default install of VS 2010, won't have the Microsoft Visual Studio Test Controller 2010 tool.
To create the necessary tables to store the test results, all you need to do is run the loadtestresultsrepository.sql script against your database.
You'll find this script at:
x86 - C:\Program Files\Microsoft Visual Studio 10\Common7\IDE
x64 - C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
Taken from:
MSDN: How to: Create a Load Test Results Repository Using SQL
Visual Studio strictly requires SQL Server for the load test store. If you don't have a SQL Server database, you cannot save test run data. All you can do is browse the result immediately after a test run, and perhaps copy-and-paste the test details into Excel. After you close the result, it's gone for good.
However, the database does not have to be on your local machine. Is there any chance you can get access to SQL Server somewhere else on your network?
You have to run "Microsoft Visual Studio Test Controller 2010 Configuration Tool" (found in Visual Studio start menu folder) to configure the database before use.
Setting the connection string is done in Test (menu) > Manage Test Controllers. This dialog allows you to select the Controller (or 'Local - No controller' for local tests) and also allows you to set the connection string to the load test results store.
Related
When trying to apply a DACPAC to an Azure SQL Database I'm getting the following from sqlpackage.exe:
*** An error occurred during deployment plan generation. Deployment cannot continue.
The Element or Annotation class SqlDatabaseOptions does not contain the Property class CatalogCollation.
I've managed to use VS2017 with SSDT to create a package and then deploy it to another database using the SQL Server Object Explorer but it fails when I use sqlpackage.exe found in
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130
The Azure SQL Database Compatibility Level is set to 140 so I'm not sure if SSDT (v 15.6.0) is using a more modern version of sqlpacakage.exe, or where I would find it? I've also tried to run it from the Azure SQL Database Deployment VSTS task and get the same result.
I've tried mapping the command line switches found in this window but again, I still get the same error.
Is there a version of sqlpackage.exe that SSDT is using that I can't find, or is it a parameter that I'm missing?
For reference this is the command that I'm using:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130>sqlpackage.exe /SourceFile:"generated.dacpac" /Action:Publish /TargetServerName:"xxxxxxx.database.windows.net" /TargetDatabaseName:"xxxxxxx" /TargetUser:"xxxxxx" /TargetPassword:"xxxxxxx" /TargetTimeout:120
It seems you may need to update Microsoft SQL Server Data-Tier Application Framework on your computer. Please download the latest version here. After installation, you will find it on the following path C:\Program Files (x86)\Microsoft SQL Server\130\DAC\bin\SqlPackage.exe” and updates independently of SSDT / SSMS.
SSMS has its own version of SqlPackage. SSDT has its own version also, which you may find at C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130.
Azure SQL is a PaaS Service which means it receives update transparently and relatively often with a new compatibility level.
Azure SQL is now 150.
When you create a new database it will be configured using the latest version.
However, your machine, your deployment agents might not have the latest tooling deployed.
When the tooling does not match the compatibility level of your database, the deployment will fail.
If you are deploying using VSTS Hosted Agent you are not in control, and it will always lag a little behind. In that case, the easiest fix is to reduce your database Compatibility level.
This is quite easy as you just need to run an SQL Statement on the database as follow:
ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = 130;
Continuous Build Database Project fails when building on TFS server. We have Visual Studio 2013 Shell (Integrated) installed. There does not appear to be a way to install SQL Server Data Tools 2013 thru' Tools > Extensions and Updates... menu.
The redacted error is below...
C:\TFSBuild\XXX\XXX\Database_CI\Sources\Database\XXX\XXX.sqlproj (126): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Has anyone experienced this? Is there a solution or work-around? Is SSDT available for VS 2013 Shell for SQL Server 2014?
I have recently installed the Visual Studio Shell (Isolated) and (Integrated) on our build server and it does not include the SQL Server tooling components. I found out that SQL Server tooling is built in to the following versions of Visual Studio (see here):
Express for Web,
Express for Windows Desktop,
Professional,
Premium, and
Ultimate
I would recommend installing at least the Professional version and then you should get the SQL Server Data Tools components that are required for building.
SQL Server Tooling is now built into the above listed versions of Visual Studio 2013 (SSDT and Visual Studio versions) and the latest March update of Visual Studio 2013 now includes SQL Server 2014 support (SQL Server Data Tools for SQL Server 2014 is available.)
To force your build to use the correct version of MSBuild set the Process - Advanced - MSBuild arguments = "/p:VisualStudioVersion=12.0" (without the quotes) as shown.
You can download SSDT for VS2012 here and that should get the database pre-reqs on your build server.
I do see mention of "Sql Server Tooling in Visual Studio 2013" on this landing page, and I think it implies these tools should be available with the shell, so if you could, check to see if you have that targets file somewhere on your build server.
Go into C:\Program Files(x86)\ and do a "dir Microsoft.Data.Tools.Schema.SqlTasks.targets /s /b" and see if something comes up.
Right now it's hard-coded to this location:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets
You might want to see if the file already exists, but in another location, like in an "v12.0" folder instead of the "v11.0" subfolder.
EDIT
Actually, what's the value on line 126 of your .sqlproj?
If it says this:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
Change it to read:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
Then have everyone test it using diagnostic logging, then gather the logs and compare them to make sure that version is consistent so you can start phasing out the legacy bits.
I had the same issue and fixed it by downloading and installing the following
dacframework.msi
SQLDOM.MSI
SQLLS.MSI
SQLSysClrTypes.msi
from here:
https://www.microsoft.com/en-au/download/details.aspx?id=42295
I have created an application in Visual Studio that uses a .mdf database and executes SQL scripts on it. The program imports and exports reports to and from Excel. I want to be able to give this program to team members, but they get an error "error: 52 - Unable to locate a local database runtime installation. verify that SQL Server Express is properly installed and that the Local Database Runtime feature is enabled."
I assume they get this error because they do not have SQL Server installed. Is there anyway I can include the minimum SQL Server components needed within my deployment? What is the minimum requirement? Thank you!
I have Visual Studio 2008 Database Edition, and everything worked great until the first time I tried to load a .dbproj file. These database project files work for the other developers I work with, but when I try to open it, I just get an error message "Object reference ot set to an instance of an object."
It's probably the same problem this guy is having, although he didn't do a good job of describing it and has no solution.
Every other kind of project file loads and builds and runs normally. dbproj files all generate this cryptic error. I just tried a fresh removal and reinstall of Visual Studio 2008 DE to no avail. Could this have something to do with my SQL 2005 installation? (This also works normally through SQL Server Management Studio.)
**
UPDATE
**
Probably even more importantly, this same error occurs when I try to make a new dbproj file. Every other type of project can be created no problem.
You need to tell Visual Studio the correct instance of SQL Server to use for validation.
Tools>Options>DatabaseTools
Change the settings in "Data Connections" and "Design-time Validation Database" to reflect the correct instance.
After many failed re-configurations and re-installations, a member of my team discovered the problem!
Under Tools > Options > Database Tools > Design-time Validation Database, there is an option to set your SQL Server Instance Name. Visual Studio automatically picks this when it's installed.
The key is that Visual Studio doesn't necessarily pick the right one. I happen to have 3 SQL server instances on my machine. SQLEXPRESS (a 2005 instance that Visual Studio installed alongside itself), SQLEXPRESS2005, a 2005 instance I installed, and SQLEXPRESS2008, which I also installed.
Visual Studio had configured itself to connect to the SQLEXPRESS2008 instance, even though it only supports SQL2005 dbproj files by default. By opening this dialogue, and updating the server instance name, the error no longer appeared and I was able to open dbproj files:
I have been using a database project in visual studio 2010 to create a database. Visual Studio makes this process really easy to deploy the database and deploy updates. The issue I have is how I can get visual studio to create a script that will build the database that I can use on a QA or production system.
I thought that building the project would create a SQL file that did this but this does not seem to be true. Can someone please advise on how I can do this or what simple step I am clearly missing.
As strange as it may sound, Visual Studio does not create a SQL file to deploy your database when you perform a Build.
Instead, this occurs at Deploy time. The reason behind this lies in the way that Visual Studio makes changes to the database that you're deploying to: in order to change your database, it must first compare the project model (as defined in the files contained within the .dbproj) with that of the existing database schema to determine what changes you have made since the database was last deployed.
You then have the choice of manually executing the SQL script produced using the SQLCMD command-line utility (or through SSMS in SQLCMD mode), or alternately you can configure your Visual Studio Database Project to execute the script if you specify the following Deploy Action in project settings:
Generate a deploy script (.sql) and deploy to the database
Note that you will need to provide a connection string in project settings so VS knows where to deploy to.
When you get to the stage where you want to deploy to a QA or PROD environment, you have a couple of options:
Deploy directly within Visual Studio. In addition to the standard Debug and Release configurations that you get when you first create your Database Project, you can also create your own configurations which you could use to deploy to your QA and PROD environments (i.e. potentially with a different connection string/target database name).
Deploy from a Build Server. Install Visual Studio on a separate machine and call MsBuild against your .dbproj/.sln file with the Build and Deploy targets specified along with the appropriate connection properties.
Doug Rathbone has written a great blog post on subject if you want to learn more:
http://www.diaryofaninja.com/blog/2011/06/23/compare-amp-update-database-schemas-right-within-your-ide--part-2-automation-with-teamcity