According to the documentation, pre-release versioning is supported, with an example given of:
Within the NuSpec file, specify the version in the element
<version>1.0.1-alpha</version>
I am building from a .nuspec file; if I include this line verbatim, then run (at the package manager console):
PM> nuget pack "Nuget\protobuf-net.nuspec"
then I get a bit fat error:
Attempting to build package from 'protobuf-net.nuspec'.
NuGet.exe : Input string was not in a correct format.
At line:1 char:6
+ nuget <<<< pack "Nuget\protobuf-net.nuspec"
+ CategoryInfo : NotSpecified: (Input string wa...correct format.:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
If, however, I just use <version>1.0.1</version> and run exactly the same command, then I get:
Attempting to build package from 'protobuf-net.nuspec'.
Successfully created package 'C:\Dev\protobuf-net\protobuf-net.1.0.1.nupkg'.
And indeed, it has built correctly. My NuGet Package Manager reports version 2.0.30625.9003.
So: am I doing something wrong? or did they break something?
NuGet Version: 1.5.21005.9019
Semantic versioning was introduced in nuget 1.6. Time for an upgrade. You can use nuget update -self to update right from the command line.
Related
The problem
I am trying to install a .net core 3.1 wpf app onto a windows 2019 server using msix as the method of deployment. The windows server is up to date and should support msix, but will not install any msix package I create using the powershell command Add-AppPackage.
The packages will install on windows 10 machines if you click on the .appinstaller file and use the gui, but they will not install on the same machine if you use powershell.
What I have tried
I've went through this troubleshooting page to no avail.
I have tried different msix packages
I have tried using a local file directory
I have tried running as administrator
Code
This is an example of what I am trying to install:
Running the .appinstaller file will correctly install this uwp app.
However, this will not work:
Add-AppPackage .\TestUwp.appinstaller
Error Message
This is the error message the powershell script outputs:
Add-AppPackage : Deployment failed with HRESULT: 0x80073CF0, Package could not be opened.
error 0x8007000D: Opening the package from location TestUwp.appinstaller failed.
NOTE: For additional information, look for [ActivityId] 742e8080-11e2-0000-5f0b-3374e211d601 in the
Event Log or use the command line Get-AppPackageLog -ActivityID 742e8080-11e2-0000-5f0b-3374e211d601
At line:1 char:1
+ Add-AppPackage .\TestUwp.appinstaller
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (W:\...\.appinstaller:String) [Add-AppxPackage],
FileNotFoundException
+ FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPac
kageCommand
PS W:\[file location here]> Get-AppPackageLog -ActivityID 742e8080-11e2-0000-5f0b-3374e211d601
Time ID Message
---- -- -------
4/14/2020 9:17:50 AM 603 Started deployment Add operation on a package with main
parameter TestUwp.appinstaller and Options 0 and 0. See
http://go.microsoft.com/fwlink/?LinkId=235160 for help
diagnosing app deployment issues.
4/14/2020 9:17:50 AM 465 error 0x8007000D: Opening the package from location
TestUwp.appinstaller failed.
4/14/2020 9:17:50 AM 403 error 0x8007000D: Failure to get staging session for:
file:///W:/[file location here]/TestUwp.appinstaller.
4/14/2020 9:17:50 AM 404 AppX Deployment operation failed for package with error
0x80073CF0. The specific error text for this failure is: error
0x8007000D: Opening the package from location
TestUwp.appinstaller failed.
When you use:
Add-AppxPackage .\TestUwp.appinstaller
The path will be mapped to the positional parameter -Path. This parameter is designed to specify the path to the app package. But you are not installing the app directly. You are using an app installer file. To install from that, use:
Add-AppxPackage -AppInstallerFile .\TestUwp.appinstaller
With this command, I was able to install your package successfully.
I have VS2015 with SSDT installed, along with SSMS and the SqlServer PowerShell module (which includes the invoke-sqlcmd comand), and yet If I try to execute a query against an Azure SQL Data Warehouse like so:
invoke-sqlcmd -Query "Select top 5 * from customer" -ConnectionString "Server=tcp:my.database.windows.net,1433;Database=Customer; Authentication=Active Directory Integrated; Encrypt=True; "
I get the following error:
invoke-sqlcmd : Unable to load adalsql.dll (Authentication=ActiveDirectoryIntegrated). Error code: 0x2. For more information, see
http://go.microsoft.com/fwlink/?LinkID=513072
At line:1 char:1
+ invoke-sqlcmd -Query "Select top 5 * from vwOffer" -ConnectionStrin ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Invoke-Sqlcmd], SqlException
+ FullyQualifiedErrorId : SqlExectionError,Microsoft.SqlServer.Management.PowerShell.GetScriptCommand
invoke-sqlcmd :
At line:1 char:1
+ invoke-sqlcmd -Query "Select top 5 * from vwOffer" -ConnectionStrin ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ParserError: (:) [Invoke-Sqlcmd], ParserException
+ FullyQualifiedErrorId : ExecutionFailureException,Microsoft.SqlServer.Management.PowerShell.GetScriptComman
If I try and install adalsql.dll directly, I get a message stating that A higher version already exists and I can see the both versions of the dll can be found here:
C:\Windows\SysWOW64\adalsql.dll
C:\Windows\System32\adalsql.dll
and yet, invoke-sqlcmd cant find it. Any idea how to either (A) register the existing dll so invoke-sqlcmd can find it or (B) uninstall it so that it can be re-installed?
Incidentally, I am able to use Active Directory Authenticatoin with the 32-bit SQLCMD.exe, so I know the 32 bit dll is working fine. It's just the 64 bit dll that isn't loading properly...
So, this problem vexed me as well. I'm unclear as to how it happened, but maybe it's just coincidence that it happened when I installed the latest version of SSMS. My fix was to:
Navigate to Add or Remove Programs
In the little search window type sql, or just go find: "Active Directory Authentication Library for SQL Server".
Note: This will not be in Windows' installed programs list if you have installed Visual Studio 2019. You can run the same installer by invoking MsiExec.exe /I{6BF11ECE-3CE8-4FBA-991A-1F55AA6BE5BF} from a command prompt.
Uninstall that little guy
Navigate here and download the latest ADAL library (pick x64):
https://www.microsoft.com/en-us/download/confirmation.aspx?id=48742
Just for kicks, reboot
Your stuff should now properly load adalsql.dll!
Update #3, 2020-07-13: Installing the older version works, but is vulnerable to being clobbered by the SSMS and VS2019 installers. The reason the new version of ADAL doesn't work is because its installer fails to add a registry entry pointing to the 64-bit version of adal.dll. I added an answer below which includes the missing registry value, which you can add yourself. Once that's done, you should never need to do this dance again. - #Tullo_x86
The bewilderingly simple solution to this annoying problem
Ensure you actually have ADAL installed (the existence of C:\Windows\system32\adal.dll is plenty)
Paste this into a .reg file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSADALSQL]
"TargetDir"="C:\\Windows\\System32\\adal.dll"
Double-click the .reg file to install that value
You're done. Go celebrate!
Explain WTF is going on. Why this is necessary?
This error happens because the .NET adapter for SQL Server can't find adal.dll. But why is this? It's installed, right?
Well, the installer for the latest version of ADAL (packaged with VS 2019 and the latest version of SQL Server Management Studio) adds a registry entry for the 32-bit version of the DLL (at C:\Windows\SysWOW64\adal.dll), but does not add the entry for the 64-bit version (which gets installed to C:\Windows\system32\adal.dll). If you build and run your application in 32-bit mode, you'll never see this bug manifest.
This is simply a bug in the ADAL installer. Presumably it wasn't detected by Microsoft because both Visual Studio and SSMS are 32-bit applications and thus don't go looking for the 64-bit version.
In my case culprit was VS 2019.
It has newer version of ADALSQL package. For me it was at path "C:\ProgramData\Microsoft\VisualStudio\Packages\sql_adalsql,version=16.0.61903.25110,chip=x64,language=en-US", which I uninstalled and installed desired version to resolve the issue.
Hope this helps!
In my case, add/remove programs didn't show any installed instances of "Active Directory Authentication Library". Yet, trying to install the library would fail saying a newer version was installed.
I un-wedged myself by opening the registry editor (regedt32) and using the Find feature from
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer
looking for adalsql.
That got a hit with containing keys
DisplayName: Active Directory Authentication Library for SQL Server
DisplayVersion: 15.0.1300.359
along with, importantly, a path to the associated installer. For me it was something like c:\windows\installer\4c334521.msi. I ran that msi and was finally able to "uninstall". After that, running the installer from the 'library' link above finally worked.
Or you if planned to upgrade SSMS in the time being, simply uninstall "Active Directory Authentication Library for SQL Server", and repair SSMS.
Next time you upgrade SSMS it won't broke anything. SSMS bring his own adalsql.dll, and know how to upgrade it when you upgrade SSMS. But if you had installed adalsql with something else (or using https://www.microsoft.com/en-us/download/confirmation.aspx?id=48742 ), SSMS is somehow broken.
I can not install this with Package Manager Console:
Install-Package Microsoft.EnityFrameworkCore.Sqlite or Install-Package Microsoft.EnityFrameworkCore.Tools. It is returning:
Install-Package : Unable to find package 'Microsoft.EnityFrameworkCore.Sqlite'
At line:1 char:1
+ Install-Package Microsoft.EnityFrameworkCore.Sqlite
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Install-Package], Exception
+ FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
Your Help will be so much helpfull. Thank you
Firstly, you made a spell mistake on entity word (you are using enity). So it cannot find the right package. The right command should be
Install-Package Microsoft.EntityFrameworkCore.Sqlite not
Install-Package Microsoft.EnityFrameworkCore.Sqlite
Details please reference UWP - New Database. This article provides the correct command you can copy and use.
Additionally, EF Core requires Microsoft.NETCore.UniversalWindowsPlatform version 5.2.2 or greater. Please following the document for checking and upgrade.
Ref:
Nuget Versioning
SemVer
The nuget versioning documentation reads:
SemVer also introduces the concept of a build number for those creating daily or continous builds. This is not supported in the public NuGet.org gallery.
It says it's not supported in nuget.org gallery but i'm wondering specifically how nuget.exe -update or -install or the Package Console in VS handles it...
Take a look at SemanticVersion.cs in the Nuget codebase. This provides the following regex to validate the provided version. If the regex doesn't match, the version is invalid:
new Regex(#"^(?<Version>\d+(\s*\.\s*\d+){0,3})(?<Release>-[a-z][0-9a-z-]*)?$",
RegexOptions.Compiled
| RegexOptions.IgnoreCase
| RegexOptions.ExplicitCapture);
The format for the prerelease string strictly has to start with a dash, then a letter, then any combination of dashes and alphanumerics. No + or . allowed.
Try and pack with anything other than a valid version and you will get:
Attempting to build package from 'ConsoleApplication1.csproj.nuspec'.
'1.0.1+421.500' is not a valid version string.
Parameter name: version
If you've somehow got a package with an invalid version, then the nuget packaging process must have been bypassed and I can only assume attempting to push it will have unpredictable results.
I used Nuget to install the "Microsoft ASP.NET Web API Client Libraries" to get the latest System.Net.Http assembly for use in Windows Phone 7.1 XNA and Silverlight projects. It installs just fine into my WP7.1 XNA projects, but doesn't allow me to install it into the WP7.1 Silverlight projects. I even tried installing it directly from the Package Manager Console into a newly created WP7.1 Silverlight project and got this Error response:
PM> Install-Package System.Net.Http
Attempting to resolve dependency 'Microsoft.Net.Http (≥ 2.0.20710.0 && < 2.1)'.
You are downloading Microsoft.Net.Http from Microsoft, the license agreement to which is available at http://www.microsoft.com/web/webpi/eula/MVC_4_eula_ENU.htm. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.
Successfully installed 'Microsoft.Net.Http 2.0.20710.0'.
You are downloading System.Net.Http from Microsoft, the license agreement to which is available at http://www.microsoft.com/web/webpi/eula/MVC_4_eula_ENU.htm. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.
Successfully installed 'System.Net.Http 2.0.20710.0'.
Successfully uninstalled 'Microsoft.Net.Http 2.0.20710.0'.
Install failed. Rolling back...
Install-Package : Could not install package 'Microsoft.Net.Http 2.0.20710.0'. You are trying to install this package into a project that targets 'Silverlight,Version=v4.0,Profile=WindowsPhone71', but the package does not contain any assembly references that are compatible with that framework. For more information, contact the package author.
At line:1 char:16
+ Install-Package <<<< System.Net.Http
+ CategoryInfo : NotSpecified: (:) [Install-Package], InvalidOperationException
+ FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand
Is System.Net.Http compatible with WP7.1 Silverlight projects, and if so, how can I get it working?
Thanks
Dan Roth (the owner of the System.Net.Http Nuget package) responded via email: "System.Net.Http.dll is not support on XNA, Phone or Silverlight at this point. It is only support on .NET 4 (through ASP.NET Web API), .NET 4.5. and the .NETCore Profile in Windows 8." So that is the unfortunate answer to this question.
As was pointed out by Dan, the System.Net.Http NuGet package has been deprecated in favor of Microsoft.Net.Http. For the latter we shipped an update that allows targeting Windows Phone 7.1.
We're working on shipping a stable release but we don't have a date yet.
since this comes up 1st on google, the beta package now supports windows phone 7.1 projects
to install user package manager console
PM> Install-Package Microsoft.Net.Http -Pre
Click here for project home page