* starts of sqlprojectsservice
* copy to mssql
* adding all the boilerplate
* updating service call structures
* Fixing up test mocks
* Adding comments to all the bindings
* blank space
* swapping for Promise; adding vscode-mssql type bindings
* patching
* Add validation for new file names for sql projects
* Addres comments and add validation for new project dialog
* Address comments
* Address comments on test
* Fix tests
* Remove extra error messages and rename file
* Address comments
* Fix tests
* Add test file back
* Add dropdown populated with projects in current workspace in Update Project from database dialog for target project location
* Select first from the list if no project is preselected
* Address comments
* add import permissions option to create project from db dialog
* change 'import' to 'include'
* update azdata dependency version
* update STS to 4.3.0.37
* fix test
* Set target platform for mssql vscode extension- create project from db feature
* Addressed comments
* Address comment to add EngineEdition information in vscode-mssql.d.ts
* download Microsoft.Build.Sql sdk and extract
* cleanup extracted folder and nuget
* add constants
* cleanup
* remove package-lock.json
* making outputChannel required and some cleanup
* only download if the files aren't already there
* Add todo
* add try catches
* addressing comments
* add 'open in designer' to context menu of tables in sql projects
* fix tests
* Address comments
* enable table designer for sql database proj
* update label and issues on init
* vbump sts
* use promisified fs
* pr comments
Co-authored-by: Alan Ren <alanren@microsoft.com>
* Add sqlproj property to trace the origin of the project.
As part of the database migration process (schema conversion, in particular) we want to be able to tell when converted schemas are being built/deployed to the actual database server. Given that we rely on the SQL Database Projects ADS extension for the compilation/deployment, we don't have too many options other than updating the said extension.
The suggested approach is to make the following changes:
1) Add new property to the sqlproj file (called `DatabaseSource`), which will maintain the origin(s) of the project. The property can contain multiple values (separated by semicolon), in case same project contains objects produced by multiple sources (extract schema, convert from another database, etc.).
2) During build and deploy actions, send the well-known values from the newly added property to the telemetry. We don't want to send any random value of the property, as it may raise some privacy concerns. Instead we define a list of the well-known values that we know do not carry any personal information and send those, if they are specified.
This change adds all necessary APIs to the SQl Database projects extension which will be consumed by our migration extensions to populate new `DatabaseSource` property.
* Use `undefined` instead of `null`
Co-authored-by: Kim Santiago <kisantia@microsoft.com>
* add more telemetry for sql database projects
* add publishToContainer events
* send target platform when publishing
* add duration for createProjectFromDb and updateProjectFromDb
