- Additional Q&A about breaking changes can be found here
- To ask a question about breaking changes use this
| 7364462 | xplat Microsoft.Portal.Tools to ship correctly named target file dotnetcore correct ordered target import Expected Errors: - those that use VS GUI for installing NuGet packages will get warning MSB4011: "Microsoft.Portal.Tools.5.0.303...\build\Microsoft.Portal.Tools.targets" cannot be imported again. It was already imported at "...\Microsoft.Portal.Tools.5.0.303....\build\Microsoft.Portal.Tools.V2.targets (3,3)". This is most likely a build authoring error. This subsequent import will be ignored. Solution: - Your \*.csproj has an import to both Microsoft.Portal.Tools.targets and Microsoft.Portal.Tools.V2.targets. Drop the import to Microsoft.Portal.Tools.V2.targets and retain the import to Microsoft.Portal.Tools.targets. Reason For Breaking Change - xplat PackageReference syntax requires targets file to be named the same as the NuGet package for correct ordering of imports. - NuGet convention states that build\ targets should have the same name as the NuGet Package. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7343607 | Add dependency MSBuild DLLs to Bundle This change introduces some required DLLs for running Bundle.exe in certain stand-alone configurations (outside of an MSBuild pipeline) which were previously unaccounted for. This change is not expected to be breaking. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7278961 | Add support for pin part to Dashboard experience into msportalfx-test Expected Errors: - Extensions running tests on pinning a part or blade to dashboards will have their tests fail as the new pin to dashboard pane will launch and tests will timeout with an exception. - Extension that run pin tests should also ensure that full portal is instantiated during tests with Dashboards accessible as pin functionality needs access to recent dashboards for pinning. Solution: - To continue running tests upgrade to the latest Microsoft.Portal.TestFramework.CSharp nuget version 1.0.210.0 or higher. The test framework will automatically handle pinning a blade to the most recent dashboard. - For pin tests that make use of pinning of a part using Fx/Pinner/Pin function calls to framework or that validate pinning of extension developed parts, should now handle the context pane opening in tests by finding the pin context pane and then pin button and clicking on the pin button. Reason For Breaking Change New pin to any dashboard functionality launches a context pane for users to select a dashboard or create new. This new UI flow will cause existing tests to fail if they aren't handling the context pane. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7261315 | Normalize msportalfx-test to import/from pattern **Expected Errors:** - After updating to the latest Msportalfx-Test framework, you may get the following compile error: `This module is declared with using 'export =', and can only be used with a default import when using the 'esModuleInterop' flag.` The error will be surrounded with a lot of other errors about non existent properties and implicit any types, which are rooted in the initial error mentioned above. **Solution:** - In your tsconfig.json, add a new compiler option as follow: `"esModuleInterop": true` Note that enabling `esModuleInterop` may create new errors once it is turned on like these: - `Type originates at this import. A namespace-style import cannot be called or constructed, and will cause a failure at runtime. Consider using a default import or import require here instead.` - `Type 'typeof Q' has no call signatures.` They should be few, and likely are related to your import of the Q, nconf and assert libraries. Fix for Q and other errors as such: Before: `import * as Q from "q";` After: `import Q from "q";` **Reason For Breaking Change** - Normalization of import pattern improves the code maintainability and import/from is the pattern that aligns with ES6. The current import/require pattern is maintained and still works. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7232935 | Obsolete old file download control **Expected Errors:** You will hit compilation error when using the below view models as they are getting obsoleted, MsPortalFx.ViewModels.Controls.FileDownload MsPortalFx.ViewModels.Controls.FileDownloadButton **Solution:** Please migrate to the new AMD modules in Fx/Controls/FileDownload for download scenarios. **Reason For Breaking Change** MsPortalFx namespace in non-AMD module. For perf reasons and using new api pattern we have exposed AMD modules under Fx/Controls and asking partners to migrate to new API patterns. Please refer to https://aka.ms/portalfx/breaking for more details. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7216444 | [Hubs] [Breaking change] Obsolete MsPortalFx.Base.Net **Expected Errors:** - Expect compile-time errors when using APIs in MsPortalFx.Base.Net module. **Solution:** - Please use MsPortalFx.Base.Net2 or preferably the "Fx/Ajax" module for the functionality previously used in MsPortalFx.Base.Net **Reason For Breaking Change** - MsPortalFx.Base.Net was deprecated in 2017. marking as obsolete so these older APIs can be removed in a future SDK. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7212383 | update to eslint v7 Expected Errors: - no known expected errors however teams with a high level of customization e.g using rules that are now deprecated may need to update per the eslint7 migration guide. Solution: - Its unlikely that you will be impacted however if you are follow the relevant eslint7 migration guide https://eslint.org/docs/user-guide/migrating-to-7.0.0#breaking-changes-for-users Reason For Breaking Change - fixes an eslint bug on windows that we contributed back impacts our workflow - replaces synchronous CLIEngine with new async ESLint api | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7165931 | Deprecate/Obsolete old Donut/Gauge controls **Expected Errors:** You will hit compilation error when using MsPortalFx view models for the below ontrols as these are getting obsoleted. MsPortalFx.ViewModels.Controls.Visualization.Donut MsPortalFx.ViewModels.Controls.Visualization.QuotaGauge MsPortalFx.ViewModels.Controls.Visualization.SingleValueGauge **Solution:** Please migrate to the new AMD modules in Fx/Controls/ Fx/Controls/Donut Fx/Controls/QuotaGauge Fx/Controls/SingleValueGauge **Reason For Breaking Change** MsPortalFx namespace in non-AMD module. For perf reasons and using new api pattern we have exposed AMD modules under Fx/Controls and asking partners to migrate to new API patterns. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7103953 | [Hubs][Breaking change] Remove enableSupportTroubleshoot from ResourceMenuOptions **Expected Errors:**
**Solution:**
**Reason For Breaking Change**
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7102872 | Remove HeroBanner and other already obsoleted APIs **Expected Errors:**
**Solution:**
**Reason For Breaking Change**
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7066128 | Update Portal SDK to TypeScript 3.9 **Expected Errors:** There may be typing errors where there were none before, due to the improved type inference, especially with callbacks and union types. **Solution:** Please review the [Breaking Changes in TypeScript](https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes) wiki to understand the breaking changes and options to re-solve issues. **Reason For Breaking Change** The TypeScript compiler in use by the SDK has been upgraded to 3.9 (from 3.5). There are a few breaking changes in the compiler itself. See [Breaking Changes in TypeScript](https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes). There are a lot of improvements and new features in the language and bug fixes / improvements in the compiler. Please read the articles for [3.6](https://devblogs.microsoft.com/typescript/announcing-typescript-3-6/), [3.7](https://devblogs.microsoft.com/typescript/announcing-typescript-3-7/), [3.8](https://devblogs.microsoft.com/typescript/announcing-typescript-3-8/) and [3.9](https://devblogs.microsoft.com/typescript/announcing-typescript-3-9/) if you are interested in the full details of what changed since 3.5. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7064237 | Deprecate StaticSection **Expected Warnings:** MsPortalFx.ViewModels.Forms.StaticSection.ViewModel is no longer supported. **Solution:** Please use Fx/Controls/Sections in place of this control. You might need to change the template a little as the StaticSection supported adding children directly in the template, whereas the Section control only allows adding children via the ViewModel. **Reason For Breaking Change** The old variants of controls are being deprecated for the newer more performant AMD versions of controls. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063649 | Deprecate old selector models **Expected Errors:** MsPortalFx.ViewModels.Forms.CreatorAndSelectorV2 MsPortalFx.ViewModels.Controls.Wizard MsPortalFx.ViewModels.Forms.Selector - [...].[...] is no longer a supported navigation/layout model. Please redesign the blades for better full screen blade experiences. **Solution:** Redesign
the blades for better full screen blade experiences. **Reason For Breaking Change** These three controls are no longer a supported navigation/layout model and has been communicated as
deprecated for 2+ years. Extensions should redesign the blades for a better full-screen experience. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063623 | Deprecate old list view The MsPortalFx.ViewModels.Controls.Lists.ListView and MsPortalFx.ViewModels.Controls.Lists.Gallery controls are being deprecated. Going forward extensions should use "Fx/Controls/ListView" instead. Build processes may run into the following errors. TsLint rule violations: "ViewModel is deprecated: MsPortalFx.ViewModels.Controls.Lists.ListView is deprecated." To resolve the violations replace MsPortalFx.ViewModels.Controls.Lists.ListView and MsPortalFx.ViewModels.Controls.Lists.Gallery controls with the "Fx/Controls/ListView" control. SpecPickerExtenders may also run into compilation errors such as: "is not assignable to type 'SpecPickerExtender'" "'selectionMode' in type '' is not assignable to the same property in base type 'SpecPickerExtender'" To fix the SpecPickerExtender change usage of "MsPortalFx.ViewModels.Controls.Lists.ListView.SelectionMode" to "HubsExtension.Azure.SpecPicker.SelectionMode". PairedTimeline usage may also run into compilation errors such as: "is not assignable to parameter of type 'ExtensionOptions'" "Property 'selectable' in type '' is not assignable to the same property in base type 'ExtensionOptions'." "Property 'selectionMode' in type '' is not assignable to the same property in base type 'SelectableOptions'" To fix the PairedTimeline change usage of types from "MsPortalFx.ViewModels.Controls.Lists.ListView" to equivalent types from "Fx/Controls/PairedTimeline". | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063515 | Deprecate old chart controls **Expected Errors:** You will hit tslint errors when using the below view models as they are getting deprecated, MsPortalFx.ViewModels.Controls.Visualization.Chart MsPortalFx.ViewModels.Controls.Visualization.SimpleChart **Solution:** Please migrate to Fx/Controls/LineChart or Fx/Controls/BarChart or Fx/Controls/AreaChart or Fx/Controls/ScatterChart. **Reason For Breaking Change** MsPortalFx namespace in non-AMD module. For perf reasons and using new api pattern we have exposed AMD modules under Fx/Controls and asking partners to migrate to new API patterns. Please refer to https://aka.ms/portalfx/breaking for more details. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063498 | Deprecate/Obsolete old balloons **Expected Errors:** Usage of the old `Balloon` view models and options (i.e. `MsPortalFx.ViewModels.Controls.Balloon` and `MsPortalFx.ViewModels.Controls.DockedBalloon`) will be flagged as a compile-time TSLint error at build time: * @deprecated [...][Docked]Balloon[...] is deprecated. Use Fx/Controls/InfoBalloon instead. * Please refer to https://aka.ms/portalfx/breaking for more details. 
**Solution:** Please use Fx/Controls/InfoBalloon instead: **Reason For Breaking Change:** This control has a better accessibility support in the new variant. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063490 | Deprecate old controls: MsPortalFx.ViewModels.Controls.InfoBox, MsPortalFx.ViewModels.Forms.CustomHtml, MsPortalFx.ViewModels.Forms.Section **Expected Errors:** Users of these controls would see a warning which says that the control is deprecated and should be replaced by a newer control.
**Solution:** Please use the newer control defined under "Fx/Controls" instead of using MsPortalFx controls. Example, import CustomHtmlfrom "Fx/Controls/CustomHtml" instead of MsPortalFx.ViewModels.Forms.CustomHtml. The deprecated controls and their replacements are mentioned below: Deprecated Control -> Replacement control MsPortalFx.ViewModels.Controls.InfoBox -> Fx/Controls/InfoBox MsPortalFx.ViewModels.Forms.CustomHtml -> Fx/Controls/CustomHtml MsPortalFx.ViewModels.Forms.Section -> Fx/Controls/Section **Reason For Breaking Change** We are no longer supporting these controls. They are deprecated and should be replaced by corresponding newer controls. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063486 | Remove old controls **Expected Errors:** The following interfaces and classes have been marked as of type `Obsolete` and their usages will be flagged as compile errors at build time: MsPortalFx.ViewModels.Controls.Splitter.Options and MsPortalFx.ViewModels.Controls.Splitter.ViewModel MsPortalFx.ViewModels.Controls.SearchBox.Options and MsPortalFx.ViewModels.Controls.SearchBox.ViewModel MsPortalFx.ViewModels.Controls.Visualization.ProgressBar.Options, MsPortalFx.ViewModels.Controls.Visualization.ProgressBar.Contract, and MsPortalFx.ViewModels.Controls.Visualization.ProgressBar.ViewModel MsPortalFx.ViewModels.Controls.TextBlock.Options and MsPortalFx.ViewModels.Controls.TextBlock.ViewModel MsPortalFx.ViewModels.Controls.Forms.CopyableLabel.Options, MsPortalFx.ViewModels.Controls.Forms.CopyableLabel.Contract, and MsPortalFx.ViewModels.Controls.Forms.CopyableLabel.ViewModel MsPortalFx.ViewModels.Controls.SimpleButton.Options and MsPortalFx.ViewModels.Controls.SimpleButton.ViewModel Additionally, `MsPortalFx.ViewModels.PartOperationList.progressBarViewModel` is getting obsoleted: please do not use this API field anymore as it is of type `Obsolete` and will consequently generate compile time build errors. **Solution:** Please use the corresponding "Fx/Controls" entities in the place of the obsolete items above e.g. "Fx/Controls/Splitter" instead of "MsPortalFx.ViewModels.Controls.Splitter" etc. These can all be discovered at https://aka.ms/portalfx/playground * Please refer to https://aka.ms/portalfx/breaking for more details. **Reason For Breaking Change** This control has a one-to-one mapping with the newer control. These can be easily replaced (with minimal hand coding) if you use the tool from Replacement tool. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063465 | Deprecate old MsPortalFx map **Expected Errors:** You will hit tslint errors when using MsPortalFx.ViewModels.Controls.Visualization.Map view models as they are getting obsoleted, **Solution:** If you are using basic map, please migrate to the new AMD modules in Fx/Controls/Map. Legacy MsPortalx HexagonLayout map should be used by SQL extension only. Other extensions should migrate to Fx/Controls/Map. **Reason For Breaking Change** MsPortalFx namespace in non-AMD module. For perf reasons and using new api pattern we have exposed AMD modules under Fx/Controls and asking partners to migrate to new API patterns. Please refer to https://aka.ms/portalfx/breaking for more details. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063455 | Remove old diffeditor and deprecate old editor **Expected Errors:**
**Solution:** Please use the corresponding Fx controls instead:
They can both be found among playground controls at https://aka.ms/portalfx/playground **Reason For Breaking Change** For the old DiffEditor and old Editor controls respectively:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063452 | Deprecate/Obsolete old frame controls **Expected Errors:** You will hit compilation error when using MsPortalFx.ViewModels.Controls.Internal.IFrameV2 view model as old IFrameV2 control is getting obsoleted. You will see tslint errors when using MsPortalFx.ViewModels.Controls.Internal.IFrame view model as old IFrame control is getting deprecated and will be obsoleted in future. **Solution:** Please migrate to the new AMD modules in Fx/Controls/FrameControls if you are using MsPortalFx.ViewModels.Controls.Internal.IFrame or MsPortalFx.ViewModels.Controls.Internal.IFrameV2 controls. **Reason For Breaking Change** MsPortalFx namespace in non-AMD module. For perf reasons and using new api pattern we have exposed AMD modules under Fx/Controls and asking partners to migrate to new API patterns. Please refer to https://aka.ms/portalfx/breaking for more details. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063375 | Deprecate editscope controls **Expected Errors:** Users of these controls would see a warning which says that the control is deprecated and should be replaced by a newer control. The controls being deprecated in this Task are as follows: MsPortalFx.ViewModels.Forms.OAuthButton MsPortalFx.ViewModels.Forms.DatePicker MsPortalFx.ViewModels.Forms.Slider MsPortalFx.ViewModels.Forms.DateTimePicker MsPortalFx.ViewModels.Forms.PasswordBox MsPortalFx.ViewModels.Forms.MultiLineTextBox MsPortalFx.ViewModels.Forms.NumericTextBox MsPortalFx.ViewModels.Forms.CheckBox MsPortalFx.ViewModels.Forms.OptionsGroup MsPortalFx.ViewModels.Forms.TextBox**Solution:** Please use the newer control defined under "Fx/Controls" instead of using MsPortalFx controls. Example, import OAuthButton from "Fx/Controls/OAuthButton" instead of MsPortalFx.ViewModels.Forms.OAuthButton The deprecated controls and their replacements are mentioned below: Deprecated Control -> Replacement control MsPortalFx.ViewModels.Forms.OAuthButton -> Fx/Controls/OAuthButton MsPortalFx.ViewModels.Forms.DatePicker -> Fx/Controls/DatePicker MsPortalFx.ViewModels.Forms.Slider -> Fx/Controls/Slider MsPortalFx.ViewModels.Forms.DateTimePicker -> Fx/Controls/DateTimePicker MsPortalFx.ViewModels.Forms.PasswordBox -> Fx/Controls/PasswordBox MsPortalFx.ViewModels.Forms.MultiLineTextBox -> Fx/Controls/MultiLineTextBox MsPortalFx.ViewModels.Forms.NumericTextBox -> Fx/Controls/NumericTextBox MsPortalFx.ViewModels.Forms.CheckBox -> Fx/Controls/CheckBox MsPortalFx.ViewModels.Forms.OptionsGroup -> Fx/Controls/OptionsGroup MsPortalFx.ViewModels.Forms.TextBox -> Fx/Controls/TextBox **Reason For Breaking Change** We are no longer supporting these controls. They are deprecated and should be replaced by corresponding newer controls. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063363 | Remove editscope controls with less than 10 usages **Expected Errors:** The following interfaces and classes have been marked as of type `Obsolete` and their usages will be flagged as compile errors at build time: MsPortalFx.ViewModels.Forms.CustomValueSlider.ViewModel MsPortalFx.ViewModels.Forms.DateTimeRangePicker.Options and MsPortalFx.ViewModels.Forms.DateTimeRangePicker.ViewModel MsPortalFx.ViewModels.Forms.DayPicker.Options and MsPortalFx.ViewModels.Forms.DayPicker.ViewModel MsPortalFx.ViewModels.Forms.DurationPicker.Options and MsPortalFx.ViewModels.Forms.DurationPicker.ViewModel MsPortalFx.ViewModels.Forms.RangeSlider.Options and MsPortalFx.ViewModels.Forms.RangeSlider.ViewModel MsPortalFx.ViewModels.Forms.TimePicker.Options and MsPortalFx.ViewModels.Forms.TimePicker.ViewModel **Solution:** Please use the corresponding "Fx/Controls" entities in the place of the obsolete items above e.g. "Fx/Controls/DayPicker" instead of "MsPortalFx.ViewModels.Forms.DayPicker" etc. These can all be discovered at https://aka.ms/portalfx/playground **Reason For Breaking Change** This control has a one-to-one mapping with the newer control. It might use EditScope but has really low usage (less than 10 across all extensions). In case you rely on EditScope, you can use How to migrate page to add support for EditScope to the new control. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063320 | Update Pill APIs to not rely on MsPortalFx APIs **Expected Errors:** Pill view model's tooltip property is obsoleted as it had dependency with MsPortalFx DockedBalloon view model. Pill's DialogEditor usages will see compilation error for using the below two MsPortalFx types, MsPortalFx.ViewModels.Dialog.DialogResult MsPortalFx.ViewModels.CustomDialogButton **Solution:** For tooltip property, please migrate to use infoBalloonContent property to specify the tooltip. For MsPortalFx.ViewModels.Dialog.DialogResult type, please migrate to use DialogButton from "Fx/Composition/Dialog" For MsPortalFx.ViewModels.CustomDialogButton type, please migrate to use CustomDialogButton from "Fx/Composition/Dialog" **Reason For Breaking Change** AMD Fx APIs are getting cleaned up to not have any legacy MsPortalFx dependencies. Migrating to AMD module will be more performant and will use the latest recommended API patterns. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063314 | Remove 'size' and 'image' from infobox **Expected Errors:** 'size' and 'image' property is no longer supported in Fx/Controls/InfoBox. These will cause a compile time error if used. **Solution:** If you relied on the 'size' property, then you should now move to choosing the styling based on the appropriate control factory method (create vs createInline) for the Fx/Control/InfoBox. Please refer to the guidance on the playground for more details on when to use which variant. If you relied on the 'image' property, that is now being removed as we want to only support standard infoBox styles. You can simply remove the image from the control and set the 'style' option to get similar/identical behavior. In case you were using custom images, that is no longer supported, and unfortunately you would need to build this experience by hand using custom HTML. **Reason For Breaking Change** The removal of the 'size' property was primarily for better API segregation between the 2 types of the infoboxes as there is functional differences between the 2 variants. The removal of the 'image' property was to ensure consistency across all infoboxes and for better control on styling and theming, which custom images were hindering. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063306 | Remove 'boxSize' from checkbox **Expected Errors:** 'boxSize ' is no longer supported in Fx/Controls/CheckBox & Fx/Controls/TriStateCheckBox and will result in a compile time error **Solution:** Remove the use of 'boxSize' from checkboxes **Reason For Breaking Change** Based on design reviews and alignment to Fabric UI, checkboxes will now only have a single standard size. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063304 | Remove unused and duplicate icons **Expected Errors:** If using an icon that has been removed, you will get a building with wording similar to "This expression is not callable". **Solution:** Use the following table to find a replacement for your icon:
**Reason For Breaking Change** Certain icons will be removed since they are not used or they have an identical existing replacement. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063289 | Deprecate hotspot **Expected Errors:** Usage of the `HotSpot` view models and options will be flagged as a compile-time TSLint error at build time: * @deprecated [...]HotSpot[...] is deprecated. Use fxclick directly in your HTML template instead. * Please refer to https://aka.ms/portalfx/breaking for more details.   **Solution:** Extensions should build the HTML themselves and use `fxclick` binding to hook up on-click handlers. Please use `fxclick` instead in your own HTML template:
**Reason For Breaking Change:** This control has accessibility issues and is an old pattern of creating links. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063286 | Remove deprecated Part types **Expected Errors:** PartKind - This part is no longer supported. Use a custom part instead. - This part is no longer supported. Use Essentials control instead. Part - ResourceSummary.[...] This part is no longer supported. Please use Fx/Controls/Essentials instead. - SingValueGauge.[...] This part is no longer supported. Please use a custom part with SingleValueGauge and Metrics control. - QuotaGauge.[...] This part is no longer supported. Please use custom part with QuotaGauge and Metrics control instead. - Donut.[...] This part is no longer supported. Please use custom part with the Donut, Legend and Metrics control instead. **Solution:** - for ResourceSummary part: Please replace it with the Essentials control. - for SingleValueGauge part: Please replace it with a custom part using SingleValueGauge and Metrics control. - for QuotaGauge part: Please replace it with a custom part using QuotaGauge and Metrics control. - for Donut part: Please replace it with a custom part using Donut, Legend and Metrics control. **Reason For Breaking Change** ResourceSummary Part: This part was communicated as deprecated for over 2+ years. Extensions should move to using the Essentials control. SingleValueGauge Part: This part is a basic wrapper over existing controls and has low usage. This is easy to replace with a custom part with the SingleValueGauge and Metrics control. QuotaGauge Part: This part is a basic wrapper over existing controls and has low usage. This is easy to replace with a custom part with the QuotaGauge and Metrics control. Donut Part: This part is a basic wrapper over existing controls and has low usage. This is easy to replace with a custom part with the Donut, Legend and Metrics control. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063240 | Remove deprecated dropdowns **Expected Errors:** The following old dropdowns are removed: FxImpl.ViewModels.Forms.CreatorAndComboBox MsPortalFx.ViewModels.Obsolete.Forms.GroupDropDown MsPortalFx.ViewModels.Obsolete.Forms.FilterComboBox MsPortalFx.ViewModels.Obsolete.Forms.MultiSelectDropDown MsPortalFx.ViewModels.Obsolete.Forms.DropDownYou will see a compile time error if you are using these. As part of the above the "MultiselectDropDownFormFieldInfo' and 'HtmlBindingsType.MultiselectDropDown' have also been removed as the underlying dropdown is not supported anymore. **Solution:** For the dropdowns, you should use Fx/Controls/DropDown or Fx/Controls/ComboBox depending on what your use case is. For the grid changes, you should move using the DroDownFormFieldInfo or GroupDropDownFormFieldInfo. For some of the missing functionalities from MultiselectDropDownFormFieldInfo, those are no longer supported due to user feedback and consistency issues and if you are using any of those, feel free to reach out to the framework team to go over alternatives. **Reason For Breaking Change** The old dropdowns were obsoleted almost 3 years ago and are now being removed. The new dropdown is accessible and much more performant and should have functional parity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 7063136 | Deprecate inline editing mode in Pill **Expected Errors:** Pill InlineEditor is getting deprecated. You will see TS lint errors if you are using Pill's InlineEditor. **Solution:** Please migrate to DialogEditor or CustomEditor for your scenario. **Reason For Breaking Change** InlineEditor is getting deprecated after user feedbacks around jumpyness of the UX and the dropdown/pill movement. We want to streamline the UX with less jumpiness and recomending DialogEditor to be used uniformly. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 6623500 | [Hubs] [Breaking change] Obsolete the old hubs dropdowns | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 6623485 | [Hubs] [Breaking change] Deprecate the WidthInPixels property in PDL The PDL compiler will emit an error if the ARG browse Column entry uses the WidthInPixels property. This property has been superseded by the Width property which includes grid column units such as 'px' for pixel units and 'fr' for fractional units. For a one-to-one mapping, replace: WidthInPixels="50" with: Width="50px" However, given the benefits of using fractional units, it would be better to start with replacing this: WidthInPixels="50" with: Width="50fr" And then adjusting to suit the column for better resizing. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 6585041 | Pin Part to Dashboard Experience Expected Errors: - Extensions running tests on pinning a part or blade to dashboards will have their tests fail as the new pin to dashboard pane will launch and tests will timeout with an exception. - Extension that run pin tests should also ensure that full portal is instantiated during tests with Dashboards accessible as pin functionality needs access to recent dashboards for pinning. Solution: - To continue running tests upgrade to the latest Microsoft.Portal.TestFramework.CSharp nuget version 1.0.210.0 or higher. The test framework will automatically handle pinning a blade to the most recent dashboard. - For pin tests that make use of pinning of a part using Fx/Pinner/Pin function calls to framework or that validate pinning of extension developed parts, should now handle the context pane opening in tests by finding the pin context pane and then pin button and clicking on the pin button. Reason For Breaking Change New pin to any dashboard functionality launches a context pane for users to select a dashboard or create new. This new UI flow will cause existing tests to fail if they aren't handling the context pane. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 6449603 | Cleanup isLogo usage from code **Expected Errors:** - Usage of the `isLogo` SVG options will be flagged as compile error at build time. - SVG attribute `data-islogo` is flagged at runtime as unsupported. This has no effect on rendering. **Solution:** - Remove `isLogo`. The option has not have effect since September 2019, and this is cleanup work on our API surface. **Reason For Breaking Change** - This deprecation and removal is a simplification of the SVG options to reduce confusion on how to preserve colors on the rendered SVG. Now the embedded colors are respected, and when none are provided, they are themed in their respective context. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 6433114 | Update the OWIN library to version 4.1 Expected Errors: - The IIdentityFederationMetadataSource interface and the corresponding IdentitiyFederationMetadataSource class have been removed as they are no longer required in the new library. - The constructor for class Microsoft.Portal.Security.AzureActiveDirectory.JwtValidater does not have the IIdentityFederationMetadataSource parameter. - The constructor for class Microsoft.Portal.Security.AzureActiveDirectory.JwtValidationParameters has been changed to accept a list of signing keys instead of signing tokens. Solution: - You'll have to modify the code to meet the new variables. Reason For Breaking Change - This change upgrages to the latest OWIN v4.1. The breaking changes introduced in this work item are because of underlying changes in the latest OWIN library. - There's no concept of a SecurityToken anymore. It has been changed to SigningKeys instead. So this is going to break anyone using this class if they adopt the new SDK. - Also, the federation metadata used to be in XML format. The new federation metadata endpoint uses JSON format. So, corresponding changes have been made to how the federation metadata is read. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 6063098 | [Hubs][Breaking change] Obsolete armEndpointLowerCase in Fx/Ajax **Expected Errors:** - Expect compile-time errors when using armEndpointLowerCase from the Fx/Ajax module **Solution:** - Use the getEndpoints() function in the Fx/Ajax module to get the set of commonly-used endpoints, and lowercase the `arm` property if necessary **Reason For Breaking Change** - Unnecessary duplication with getEndpoints() | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 6016095 | Add running ESLint deprecated rule in extension build targets, breaking Expected Errors: - `Install the azure portal CLI using 'npm install -g @microsoft/azureportalcli' documentation https://aka.ms/portalfx/apclidoc` - msbuild warnings and errors corresponding to lint warnings/errors Solution: - For warnings and errors recommended approach: fix lint warnings/errors by moving to the recommended APIs. If you can't immediately implement the recommended fix you can silence the lint warning/error using standard eslint disable comments https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments. If you do this we recommend you take a work item and include a reference to that in the comment. Disabling linting will drop that use from telemetry and as such you may be broken in a future release if we remove the said API based on apparent non/usage. Reason For Breaking Change Linting will run on dev mode builds builds targeting local hosting service i.e whenever RunBundlerInDevMode=true for the following reasons - clear notification of deprecated APIs for for extension developers - telemetry for portal to understand which deprecated APIs are not in use and can be removed - telemetry for portal to understand which deprecated APIs are in heavy use and need --fix rule automation and/or documentation for migration - lint for code hygiene, we will drip feed a larger set of rules into the core ruleset over time rather then all at once to avoid large amount of linting warn/errors. if you want to be proactive update to use the recommended set, see linting in https://aka.ms/portalfx/apcli | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 5142904 | Remove 'autosize' API from viewmodel partcontainer and part composition **Expected Errors:** - Calls to `autoSize` API on the PartContainer will now break build since the API was removed. **Solution:** - Remove calls to `autosize`. If applicable, migrate to `resizeTo` API on the same container. **Reason For Breaking Change** - The API was developed as a prototype and was solely usable by a single extension. That extension already cleaned up their usage. Other usage was already not working and just dead code as such. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 5012171 | Remove the 'Browse' noPDL blade from ART browse, the 'BrowseResource' blade is the appropriate blade If you are using the Browse noPDL blade, switch your code to use BrowseResource noPDL blade. If you have used the MsPortalFx.Base.Constants.AssetTypes.BrowseBlade constant in Base.Constants.ts, switch to the MsPortalFx.Base.Constants.AssetTypes.BrowseResourceBlade constant (though the value is the same). If you have a deep link to the Browse blade (#blade/HubsExtension/Browse) switch the deep link to the BrowseResource blade (#blade/HubsExtension/BrowseResource). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 3822777 | Deprecate browse V1 (PDL + code in shell and hubs) Browse V1 has been deprecated for some time and no teams are actively using browse V1 at this point. We confirmed the usage using Kusto telemetry logs and have mitigation in place for the few pinning parts remaining. This means that the ServiceViewModel's for Browse, Grid, Security and DynamicBlade have all been set to Obsolete and implementation code in FX has been removed. Affected: PDL compiler will emit a compile error for Browse Type="ServiceViewModel". Either remove the Browse entry from PDL or change the Type to:
PDL compiler will emit a compile error for GridColumns entry, please remove that entry from PDL. PDL compiler will emit a compile error for Security entry, please remove that entry from PDL. PDL compiler will (and has) emitted a compile error for DynamicBlade entry, please remove that entry from PDL. If you have an asset type view model which referenced one of the following interfaces, it is safe to remove that reference: MsPortalFx.ViewModels.Services.Browse.Contract MsPortalFx.ViewModels.Services.DynamicBlade.Contract MsPortalFx.ViewModels.Services.GridColumns.Contract MsPortalFx.ViewModels.Services.Security.Contract Similarly, if you have an asset view model which derived from one of the following base classes, it is safe to remove that reference: MsPortalFx.ViewModels.Services.Browse.Service MsPortalFx.ViewModels.Services.DynamicBlade.Service MsPortalFx.ViewModels.Services.GridColumns.Service MsPortalFx.ViewModels.Services.Security.Service | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 3331114 | Obsolete MsPortalFx.ViewModels.Controls.PreviewTag **Expected Errors:** MsPortalFx.ViewModels.Controls.PreviewTag is no longer supported and will cause a compile time error is used. **Solution:** This control is no longer supported and would need to be replaced with custom HTML if still needed. **Reason For Breaking Change** This was a control created for internal use of preview features and is not intended to be used externally. On code scan it was determined that no extension is currently using this. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2729311 | MsPortalFx.ViewModels.Services.ResourceTypes needs clean up Most of the APIs in MsPortalFx.ViewModels.Services.ResourceTypes are being deprecated. There are performance issues with the majority of the APIs due to excessive regex use and constantly parsing the IDs. The Fx/ArmId module should be used instead: import { ArmId } from "Fx/ResourceManagement"; The ArmId namespace has two main functions, 'parse()' and 'stringify' which operator like JSON's parse and stringify. The parse takes any string value and will produce an 'ArmId' interface which at the top level contains a 'kind' property which if of type const enum ArmId.Kind. If the resource ID parsed is null or not a valid resource ID (including subscription ID or resource group ID), the kind property will be ArmId.Kind.Invalid but the function never returns null. If the kind is not Invalid, it is one of the other kinds which represents a valid ID. The stringify function takes a parsed ArmId and the ArmId.Kind for the string and produces a canonical string for that ID. This two way translation also parsing and stringifying the IDs. For optimum performance any parse() calls inside of loops or in observable subscriptions/computeds should be avoided. Intead in these cases, parse the ID once and store the resulting ArmId value which can be reasoned over many times without the penalty of parsing the resource ID. Some of the existing ResourceTypes APIs have fairly direct translations: Deprecated | New Recipe -- | -- isTenantResource(resource) | ArmId.parse(resource).kind === ArmId.Kind.TenantResource isSubscriptionId(id) | ArmId.parse(id).kind === ArmId.Kind.Subscription isResourceGroupId(id) | ArmId.parse(id).kind === ArmId.Kind.ResourceGroup isResourceId(id) | ArmId.parse(id).kind === ArmId.Kind.Resource isTagId(id) | ArmId.parse(id).kind === ArmId.Kind.SubscriptionTagValue isResourceManagerId(id) | ArmId.parse(id).kind !== ArmId.Kind.Invalid The following interfaces are replaced by a single ArmId interface with the kind property and all the properties under the follow interfaces: Deprecated | ArmId -- | -- ISubscriptionDescriptor | ArmId IResourceGroupDescriptor | ArmId IResourceManagerDescriptor | ArmId IResourceDescriptorBase | ArmId IResourceDescriptor | ArmId IDeploymentDescriptor | ArmId ITagDescriptor | ArmId Subsequently, all the following APIs should be replaced with single ArmId.parse() call: Deprecated | ArmId.parse() -- | -- parseSubscriptionDescriptor | ArmId.parse() parseResourceGroupDescriptor | ArmId.parse() parseResourceDescriptor | ArmId.parse() parseResourceManagerDescriptor | ArmId.parse() parseDeploymentDescriptor | ArmId.parse() parseTagDescriptor | ArmId.parse() And all the following build APIs should be replaced with single ArmId.stringify() call with the desired Kind: Deprecated | ArmId.stringify() -- | -- buildDeploymentId | ArmId.stringify() buildSubscriptionIdFromDescriptor | ArmId.stringify() buildSubscriptionIdFromResourceGroupDescriptor | ArmId.stringify() buildSubscriptionIdFromResourceDescriptor | ArmId.stringify() buildSubscriptionIdFromResourceGroupId | ArmId.stringify() - use ArmId.parse() on the resource group ID buildSubscriptionIdFromResourceId | ArmId.stringify() - use ArmId.parse() on the resource ID buildResourceGroupIdFromDescriptor | ArmId.stringify() buildResourceGroupIdFromResourceDescriptor | ArmId.stringify() buildResourceGroupIdFromResourceId | ArmId.stringify() - use ArmId.parse() on the resource ID buildResourceIdFromDescriptor | ArmId.stringify() For the compare functions, simply toLowerCase() each ID and use string comparison: compareSubscriptionId compareResourceGroupId compareResourceId compareResourceManagerId Similarly, for the buildLowerCaseXxx() functions, simply toLowerCase() the ID: buildLowerCaseSubscriptionId buildLowerCaseResourceGroupId buildLowerCaseResourceId Others require some work: isDeploymentId should use parse(id), then check that the kind is Resource and that the provider is 'Microsoft.Resources' and type is 'deployments' buildSubscriptionIdFromSubscriptionName (and buildSubscriptionFromId) - use `/subscriptions/${subscription}` buildResourceGroupIdFromSubscriptionAndResourceGroupName - use subscription ? `/subscriptions/${subscription}${resourceGroup ? `/resourceGroups/${resourceGroup}` : ``}` : `` buildResourceTypeFromResourceDescriptor - use armId.resourceType buildResourceTypeFromResourceId (and buildResourceTypeFromResourceManagerId) - use ArmId.parse(resourceId).resourceType buildTopmostParentResourceIdFromDescriptor - use `/subscriptions/${armId.subscription}/resourceGroups/${armId.resourceGroup}/providers/${armId.provider}/${armId.resourceTypes[0]}/${armId.resourceIds[0]}` buildParentResourceIdFromDescriptor - there is no great way to handle this case other than parsing the resource ID using ArmId.parse(), then trimming the last entry from the resourceTypes and resourceIds and then calling ArmId.stringify(). This is a special case and should be implemented locally however. isParentResource - use: const pattern = toLowerCase(parentResourceId) + "/"; return startsWith(toLowerCase(childResourceId), pattern); buildTagName - use: `${tagPrefix}:${resourceId}` buildRelatedTagName - use: `hidden-related:${resourceId}` buildLinkTagName - use: `hidden-link:${resourceId}` tryBuildResourceManagerKey - use: ArmId.parse(id) !== ArmId.Kind.Invalid ? id.toLowerCase() : null subscriptionContainsResourceGroup - use: const subscriptionArmId = ArmId.parse(subscriptionId); if (subscriptionArmId.subscription === ArmId.parse(resourceGroupId).subscription && subscriptionArmId.kind === ArmId.Kind.Subscription) {} subscriptionContainsResource - use: const subscriptionArmId = ArmId.parse(subscriptionId); if (subscriptionArmId.subscription === ArmId.parse(resourceId).subscription && subscriptionArmId.kind === ArmId.Kind.Subscription) {} resourceGroupContainsResource - use: const rgArmId = ArmId.parse(resourceGroupId); const resArmId = ArmId.parse(resourceId); if (rgArmId.subscription === resArmId.subscription && rgArmId.resourceGroup === resArmId.resourceGroup && rgArmId.kind === ArmId.Kind.ResourceGroup) {} | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2649781 | remove status from ResourceTypes.ts. Contract interface |
| 7343607 | Add dependency MSBuild DLLs to Bundle This change introduces some required DLLs for running Bundle.exe in certain stand-alone configurations (outside of an MSBuild pipeline) which were previously unaccounted for. This change is not expected to be breaking. |
| 5468245 | Investigate .NET Core support for the build This change adds .NET Core versions of some Portal SDK tools to the existing NuGet packages. (In folders "netcore30" and "netstandard20" etc.) **PLEASE DO NOT USE THE .NET CORE BINARIES YET** Support for .NET Core in the Portal SDK is not ready for broad consumption. Existing binaries in existing packages are still .NET Framework versions, and are the only type supported. If you are seeing C# build errors with the following error: "You must add a reference to assembly 'netstandard'...." then follow the answer in this StackOverflow question: https://stackoverflow.microsoft.com/questions/145700/145701#145701 |
| 6449603 | Cleanup isLogo usage from code **Expected Errors:** - Usage of the `isLogo` SVG options will be flagged as compile error at build time. - SVG attribute `data-islogo` is flagged at runtime as unsupported. This has no effect on rendering. **Solution:** - Remove `isLogo`. The option has not have effect since September 2019, and this is cleanup work on our API surface. **Reason For Breaking Change** - This deprecation and removal is a simplification of the SVG options to reduce confusion on how to preserve colors on the rendered SVG. Now the embedded colors are respected, and when none are provided, they are themed in their respective context. |
| 6133829 | [ReactBlades] Modernize ‘Az.fail(…)’, et al, to match @Chris' recent API work re: supportability Reason: Az.fail and Az.notFound both have new signatures where they expect Az.ErrorOptions instead of strings, in line with new Portal APIs on error handling. The change is only compile-time breaking, the runtime implementation will keep working with strings while teams update their TypeScript code. How to fix: Az.fail(ClientResources.error) becomes Az.fail({ message: ClientResources.error }) and Az.notFound(ClientResources.notFound) becomes Az.notFound({ message: ClientResources.notFound }) |
| 5773699 | Update TypeScript compiler to 3.5 Expected Errors: - Partner code might see some type usage errors due new a newer version of TypeScript in use. Solution: - If you see errors, these are typically because newer versions of TypeScript are typically better at inferring complex expressions. The recommendation is that you evaluate each, as they might uncover subtle bugs that would require runtime fixes. In some other cases it's just a matter of being a little more explicit about the types in use (for example, add type assertions or define the types for arrow functions or generics, etc). There aren't many breaking changes in TypeScript itself from version 3.3 to 3.5, but read the breaking changes and announcement articles to see why some new errors would surface, and also start benefiting of the new functionality: Reason For Breaking Change - Be able to leverage better tooling for improved syntax and type inferrence, as well as better compilation performance. |