Unable to install package. Lock file has not changed, Skipping lock file write - nuget

I am trying to install System.ComponentModel.Annotations through VS 2017 package manager console.
Command:
Install-Package System.ComponentModel.Annotations -Version 4.3.0
Outcome
Restoring packages for
C:\MyTest.csproj...
Installing NuGet package System.ComponentModel.Annotations 4.3.0.
Committing restore... Writing lock file to disk. Path:
C:\MyTest\obj\project.assets.json
Restore completed in 816.43 ms for
C:\MyTest.csproj.
Restoring packages for
C:\MyTest.csproj...
Committing restore... Lock file has not changed. Skipping lock file
write. Path:
C:\MyTest\obj\project.assets.json
Restore completed in 2.03 sec for
C:\MyTest.csproj.
Executing nuget actions took 4.12 sec Time Elapsed: 00:00:05.2258592
Note:
I am using .NETCoreApp1.1 framework.

Unable to install package. Lock file has not changed, Skipping lock file write
I also got the same outcome in the output windows when I restore/update that package, but I found that package was already installed to the project after checking the project Dependencies and project file(.csproj). And the outcome did not tell the installation failed, just prompting skip lock file write:
Restoring packages for C:\MyTest.csproj... Committing restore... Lock file has not changed. Skipping lock file write.
So this message comes only if that package was already installed to the project. When you got that log, you should double check the project reference, make sure if the package already installed.

One should also check if there is a Directory.Build.targets file in some parent directory of the project that defines the version of the package. If this is the case (I had this problem), VS will ignore the version you install and will keep the version defined in the file, so you have to update the version there.

Related

NU1102: Unable to find package Microsoft.Windows.SDK.BuildTools with version (>= 10.0.19041.8)

In my build pipeline, I have the following step:
I am getting the following error:
##[error]The nuget command failed with exit code(1) and error(NU1102: Unable to find package Microsoft.Windows.SDK.BuildTools with version (>= 10.0.19041.8)
When I go to the NuGet page for this package: Microsoft.Windows.SDK.BuildTools, I see that it only has one version: 10.0.18362.3-preview. I am not sure why the NuGet restore step is trying to get a higher version that does not exist. Why is this happening and how can I fix it? Note: this is my first Pipeline.
Agent Specification: Windows-2019.
From this page, you can see only two versions of the package Microsoft.Windows.SDK.BuildTools are listed:
10.0.19041.1
10.0.18362.3-preview
When open the page of version 10.0.19041.1, you can see the warning message to notify that this package version has been deprecated. But it seems that you can still download and install it.
I think the other package versions may have been permanently deleted by the owner due to some security vulnerabilities. So you no longer find them.
You can try to open your project using Visual Studio on your local machine, and change to use version 10.0.18362.3-preview in your program.

Magento 2.3.5 fresh installtion using composer results in error

I am trying to install Magento 2.3.5 using composer.
muk#muk:/var/www/html$ composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.3.5 magento23
Creating a "magento/project-community-edition" project at "./magento23"
Installing magento/project-community-edition (2.3.5-p1)
- Installing magento/project-community-edition (2.3.5-p1): Loading from cache
Created project in /var/www/html/magento23
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 463 installs, 0 updates, 0 removals
- Installing magento/magento-composer-installer (0.1.13): Loading from cache
- Installing laminas/laminas-dependency-plugin (1.0.3): Loading from cache
Plugin installation failed (include(/var/www/html/magento23/vendor/laminas/laminas-dependency-plugin/src/DependencyRewriterPlugin.php): failed to open stream: No such file or directory), rolling back
- Removing laminas/laminas-dependency-plugin (1.0.3)
[ErrorException]
include(/var/www/html/magento23/vendor/laminas/laminas-dependency-plugin/src/DependencyRewriterPlugin.php): failed to open stream: No such file or directory
create-project [-s|--stability STABILITY] [--prefer-source] [--prefer-dist] [--repository REPOSITORY] [--repository-url REPOSITORY-URL] [--add-repository] [--dev] [--no-dev] [--no-custom-installers] [--no-scripts] [--no-progress] [--no-secure-http] [--keep-vcs] [--remove-vcs] [--no-install] [--ignore-platform-reqs] [--] [<package>] [<directory>] [<version>]
I am getting following error.
Plugin installation failed (include(/var/www/html/magento23/vendor/laminas/laminas-dependency-plugin/src/DependencyRewriterPlugin.php): failed to open stream: No such file or directory), rolling back
- Removing laminas/laminas-dependency-plugin (1.0.3)
My Composer version
muk#muk:/var/www/html$ composer --version
Composer version 1.10.5 2020-04-10 11:44:22
I am using VirtualBox with Shared folder.
How can I fix it?
Note: To fix it I stopped using shared folder. Now I keep the entire code in the VM and do not use shared folder. For file synching I am using mutagen.
if anyone runs into this issue, it looks to be a problem with virtualBox and shared folders. when unzipping files, they are not immediately available in the environment.
the solution is by rkamp and is also available here:
https://stackoverflow.com/a/66413857/1470145
in short, one needs to override unzip to add a brief delay after unzipping.
I thought I had the same issue, but turned out it was something else.
The upgrade went OK for me, for a sandbox/clean 2.3.4 install, and a client project running 2.3.4.
A few things:
This could possibly be an issue with your cache, try to clear your composer laminas cache (~/.composer/cache/files/laminas usually)
Although it would complain about that, you've possibly got unmet platform requirements (php version, etc.)
Try clearing your entire composer cache (~/.composer)
Double-check the repository URL (should it be 2.3.5 or 2.3.5-p1?)
Hope that helps

Nuget.exe pack times out

As part of the build process, it packages with NuGet and pushes to NuGet server. All was OK, but after updating the NuGet version to the latest it just hangs there on the pack command.
I'm using F#Fake for the build process, and after quite a long period the nuget.exe pack command just times out:
Running build failed.
Error:
System.Exception: Process E:\Builds\projectName\build\tools\nuget\nuget.exe pack -Symbols -Version 1.0.0.0-pre -OutputDirectory "E:\Builds\projectName\build\package\out" "E:\Builds\projectName\build\package\tmp\template.nuspec" -NoPackageAnalysis timed out.
at Fake.NuGetHelper.NuGet(FSharpFunc`2 setParams, String nuspecOrProjectFile) in D:\code\FAKE\src\app\FakeLib\NuGet\NugetHelper.fs:line 423
at FSI_0005.Build.clo#163-25.Invoke(Unit _arg10)
at Fake.TargetHelper.runSingleTarget(TargetTemplate`1 target) in D:\code\FAKE\src\app\FakeLib\TargetHelper.fs:line 626
Update:
The same command directly without Fake's wrapping, hangs there for around 20 mins on the below lines:
NuGet Version: 4.4.1.4656
Attempting to build package from 'template.nuspec'.
Finally it does create the package, but never used to be that long.
I've tested with NuGet v2.8.6 and same operation takes seconds.
After some trial and error, I've discovered that any of the 4+ versions of a NuGet have the problem with taking ages to create a package.
I've stopped on v3.5.0, where packaging timings are OK.
However it had another unexpected/frustrating change, where it forces the version normalization, i.e. if requested to pack with 1.0.123.0, the nuspec is generated with 1.0.123 skipping the last 0.
Update: apparently the version normalization is a documented breaking change from version 3.4 and above.

NuGet restore works if old version 0.*, but fails with version 2.*

I've got a VSTS build, starting from a blank, originally with just Node.js bits, but now adding some C# bits.
Added the NuGet restore, build sln and vstest tasks as part of the update to the build.
Build fails on the NuGet restore task with the error around the MSTest TestAdapter ...
Restoring NuGet package MSTest.TestAdapter.1.1.11.
Restoring NuGet package MSTest.TestFramework.1.1.11.
WARNING: Unable to find version '1.1.11' of package 'MSTest.TestFramework'.
WARNING: Unable to find version '1.1.11' of package 'MSTest.TestAdapter'.
Errors in packages.config projects
Unable to find version '1.1.11' of package 'MSTest.TestFramework'.
Unable to find version '1.1.11' of package 'MSTest.TestAdapter'.
Why doesn't it pick up the MSTest package?
And even more puzzling to me ??? ...
I spotted the task was version 2.*
tried setting it to version 0.* ...
and the build works !! ... runs tests, etc.
Why does version 0.* work, yet the latest version 2.* fails?

How to exclude packages when populate_sdk in Yocto

I have a Yocto bitbake image recipe that can be built successfully.
However, the same image recipe fails when generating SDK with -c populate_sdk command.
The error seems to be caused by mixing 32-bit and 64-bit versions of libraries, which is fine when building images with only binaries, but the header files collide with each other when populating the SDK root fs:
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
file /usr/bin/curl-config from install of lib32-curl-dev-7.53.1-r0.cortexa7hf_neon_vfpv4 conflicts with file from package curl-dev-7.53.1-r0.aarch64
file /usr/include/nettle/version.h from install of lib32-nettle-dev-3.3-r0.cortexa7hf_neon_vfpv4 conflicts with file from package nettle-dev-3.3-r0.aarch64
file /usr/include/nettle/nettle-stdint.h from install of lib32-nettle-dev-3.3-r0.cortexa7hf_neon_vfpv4 conflicts with file from package nettle-dev-3.3-r0.aarch64
What is the best way to exclude 32-bit versions of libraries(recipes) when doing -c populate_sdk without excluding them entirely from the production image?
You can remove target packages from the toolchain by removing them from the TOOLCHAIN_TARGET_TASK variable and host packages by removing them from the TOOLCHAIN_HOST_TASK.
For example to remove the target package "curl-dev" from your sdk you have to add the following in your image recipe:
TOOLCHAIN_TARGET_TASK_remove = "curl-dev"
To remove the same host package from your sdk you have to add the following in your image recipe:
TOOLCHAIN_HOST_TASK_remove = "curl-dev"