* Merge conflict resolution
* Throw error for unsupported versions of Dotnet
* Fix for darwin
* Fix for all platforms
* Address comments
* Fix extensionsGaller.json
* Address comments
* Update default installation path for linux
* Fix test
* Revert default installation location change for Linux
* Address comments
* Removed extra try-catch block
* initial quick pick
* move constants
* remove commented code for now
* addressing comments
* update name
* update name in other places
* remove azure functions from name and rename file
* Automatically add intermediate folders for SQL project items.
While using the SQL database projects through the API, I noticed that project may end up in somewhat inconsistent state, where files will be added to the project, but their parent folders will not. This in turn resulted in failure to remove these folders from project - they will show up in the UI tree, but deleting them will cause an error. In order to align with how Visual Studio manages the projects, this change will ensure that all intermediate folders are present in the project, when new files or folders are added.
While this change improves project "correctness" when accessing it through SQL projects extension APIs, there is still a possibility that someone will open an "incorrect" previously created project. This change does not address it and folder removal may still fail.
* Update the code to never throw on duplicate items when adding files and folders to project.
After a conversation with the sqlproj owners, we agreed that there are no scenarios that would prompt us to throw an error, if duplicate item is being added to the project. Ultimately, the goal of such a request would be to have an item in the project file, which is already present, therefore the call becomes a no-op.
This allowed me to simplify the new code that was ensuring all intermediate folders are present in the project when adding files and folders.
* Transition to withProps in arc
* Transition to withProps inputbox
* Transition to withProps in checkbox
* Transition to withProps text
* Transition to withProps in declarative table
* Transition to withProps hyperlink
* Transition to withProps in button
* Transition to withProps radiobutton
* Transition to withProps in input
* Transition to withProps button
* Transition to withProps in text
* Transition to withProps image
* Transition to withProps declare table
* Transition to withProps in table
* Transition to withProps radio button
* Transition to withProps in image
* Transition to withProps radio button
* Transition to withProps in commit
* Transition to withProps div cont
* Transition to withProps in comp
* Transition to withProps radio card
* Transition to withProps in comp icon
* Transition to withProps card
* Transition to withProps list
* add target platform as an option in create project api
* move constant
* WIP
* show versions in dialog and create project with selected version
* validate version
* add error messages
* add test
* change version to target platform
* cleanup
* more cleanup
* use withProps
* Bump Sql Db Projects extension
* Bump azdata version for Sql Db projects
* Update package.json
Co-authored-by: Charles Gagnon <chgagnon@microsoft.com>
* Expose default database collation through 'sql-database-projects' extension API.
For the purpose of schema conversion we would need to know whether target database is configured as CI or CS. This will be used to produce a warning, if we detect a case-sensitive identifier, but database is configured as CI. In order to support this scenario we need to access `<DefaultCollation/>` property of the project.
This change adds new method to the `ISqlProject` interface that allows to read the value of the project property. There already was similar method for the SQL version/platform (`<DSP/>` property) and while working on the change, I took an opportunity to refactor the way project properties are extracted from the XML. Original code was hardcoded in the `getProjectTargetVersion` and I extracted it into separate `evaluateProjectPropertyValue` helper, that can be used in the future by any getter or access method that is supposed to return a value of the single property. This also allows us to improve the way properties are retrieved from the XML. Today the logic is very rudimentary - we read the first matching XML element with the required name. This is not correct as it does not verify the parent to be `<PropertyGroup/>`, neither it evaluates the `Condition` attributes nor property value itself. I did not invest in this, but added a TODO there explaining that the method may not perform as expected.
After the helper method was added, I updated the existing `getProjectTargetVersion` method to leverage it. The only complication here was the error throwing logic, as it was using custom error message. I preserved that, as there were tests verifying it already. For the new accessor method I did not introduce a special error message and rely on generic one I defined for use within the helper method. Additionally, for the collation we return default value of `SQL_Latin1_General_CP1_CI_AS`, if project does not have the property defined. This is what SSDT for Visual Studio shows in the UI when property is missing and I decided to align with that.
Finally, I added tests for both - original `getProjectTargetVersion` and new collation extraction method to make sure they work as expected. While working on the tests, I've noticed complaints that some rejected promises were not awaited. I added missing `await`s.
