Cant install either of the DacFx packages
StingyJack opened this issue · comments
No reason given other than the error below.
It would be nice if you could list the platform dependencies in the nupkg so we can know what is required to install this. I had to download it manually from the website as Save-Package cant find it to download a copy.
contact the package author
It would also be nice if the package actually listed the project page these extensions go to or the actual contact info for the group @msft that supports this , so I didnt have to hunt for this one, which is probably not the right one, but the closest I can find.
Install-Package : Could not install package 'Microsoft.SqlServer.DacFx.x64 140.3745.1'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.5.2', but the package does not contain any assembly references or content
files that are compatible with that framework. For more information, contact the package author.
At line:1 char:1
+ Install-Package Microsoft.SqlServer.DacFx.x64
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Install-Package], Exception
+ FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
An AnyCPU version would be fantastic. I don't like the bitness splitting since it forces me to make a choice of one or the other (or worse - both).
This package has two compatibility or usage problems, its called "x64" but is actually compiled as AnyCPU, and its marked as net46 and not net452 and lists "no dependencies",
Thanks for reporting these issues.
For net46 dependency, I'll look into getting this documented and fixed.
As for the reasoning behind the x86/x64 platform targets, the DacFx nuget package includes the Microsoft.SqlServer.Types assembly. This assembly has a native runtime dependency. Currently, that native dependency is not included in the nuget package. But in the future, this native dependency may be included, so I believe the nuget packages was authored to remain forward compatible.
Where forward compatible is generally less compatible.
The .Net 4.6 compatibility is from a String.Format call. I've been experiencing this in some PowerShell I have that uses the DacFx framework to deploy dacpacs. Had to find where this had come in and eventually managed to dig through the exception stack to find it. If you need more detials/examples I can provide those.
@kchenery - uh... not sure what you are getting at. The package doesnt list 4.6 as a dependency. Its also erroneously marked as x64 when its AnyCPU.
I'm just asking that the package be made more truthful in this regard so that someone doesn't assume they have to change their entire codebase from anycpu to have both x86 and x64, or to update everything to 4.6 if its not needed.
Sorry...not that clear. Earlier versions didnt have a net46 dependency. Its something I've stumbled on and eventually found it was a call to String.Format that had that introduced depency. An option may be to remove that particular dependency.
Is there an update on this?
We have a new nuget package that declares it's dependencies, targets ANYCPU, and supports netcoreapp2.1 and net46.
https://www.nuget.org/packages/Microsoft.SqlServer.DACFx/150.4240.1-preview
@pensivebrian - does this package also resolve the assembly binding redirect issues the existing one has?
@StingyJack - can you elaborate on an assembly redirect issues? I'm unaware of any, but willing to fix.
EDIT: Sorry @pensivebrian, I was remembering them from the Report Viewer control package, not this DacFx package at topic here.
Where would I log Report Viewer package issues?
------Unrelated---------------
Whenever I added the package to a project it would always stick these in it.
<dependentAssembly>
<assemblyIdentity name="Microsoft.ReportViewer.WinForms" />
<bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="14.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="14.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.Types" publicKeyToken="89845DCD8080CC91" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="14.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="EnvDTE" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
</dependentAssembly>
@StingyJack - It looks like the Microsoft.ReportViewer.WinForms package was not authored by Microsoft, so you'll have to use the "contact owners" link to get in touch with the owner. Official Microsoft packages will have owners that link to the Microsoft organization.
@pensivebrian - Microsoft.ReportingServices.ReportViewerControl.WebForms (I can never find this when searching for package) is the one I mean, but again this is unrelated to the OP.
EDIT: it is nice to see that someone from the SQL server team does in fact exist, though you are the only one from there I've seen over the course of about 2 years.