Fix | Dropping reference to Microsoft.Win32.Registry in netcore.

[JRahnama]

According to this announcement Microsoft.Win32.Registry is shipped with net 6 and after versions. Removing the reference in netcore csproj will eliminate the warning.

[ErikEJ]

What does this fix?

[JRahnama]

What does this fix?

Warnings on build time and also on Visual studio in referenced packages.

[David-Engel]

@JRahnama
Make sure to run the ConnectionAliasTest test manually. It gets skipped in the pipeline since the agent doesn't have permission to create aliases.

Alternatively, you could refactor the pipeline and test to rely on a static alias that we set up at the beginning of the pipeline and define in the config.json.

[codecov]

Codecov Report

Patch coverage has no change and project coverage change: +0.03 🎉

Comparison is base (102ebb7) 70.48% compared to head (20e3860) 70.51%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1974      +/-   ##
==========================================
+ Coverage   70.48%   70.51%   +0.03%     
==========================================
  Files         306      306              
  Lines       61661    61661              
==========================================
+ Hits        43460    43482      +22     
+ Misses      18201    18179      -22     

Flag	Coverage Δ
addons	92.88% <ø> (ø)
netcore	73.31% <ø> (-0.01%)	⬇️
netfx	69.10% <ø> (+0.06%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 12 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[JRahnama]

@JRahnama Make sure to run the ConnectionAliasTest test manually. It gets skipped in the pipeline since the agent doesn't have permission to create aliases. Alternatively, you could refactor the pipeline and test to rely on a static alias that we set up at the beginning of the pipeline and define in the config.json.

I did check the test. With modifying DataSource from localhost to FQDN and setting Encrypt to false it ran successfully.

Update: The change for the hostname was unnecessary and it worked fine with setting Encrypt = false only.

I will look into setting up the pipelines to be able to handle that test.

[JRahnama]

/azurepipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[JRahnama]

/azurepipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).