So I having some trouble wrapping my head around how nuget package versioning is supposed to work. As I understand it Version="6.*" (or [6.0,7.0)) means that any 6.x.x version is valid and that the default behavior is supposed to be that it's going use the lowest compatible version in that range. Correct? What I had assumed, was that it meant if it didn't already have a version in that range to use, then it would fetch the lowest version, but instead, what it seems to be doing is removing what is installed and replacing it with the lowest possible version and this is causing problems.
Example:
Project A has package foo-2.4 installed. It also has package bar-1.0 installed that has a dependency on foo-2.*. Logically, I would assume that installing package bar should be fine because it'll see foo-2.4 and use it since it's in the correct range, but instead what is happening is that it's trying to remove foo-2.4 and replace it with foo-2.0 and that fails because the package manager detects a downgrade and aborts the installation.
Am I misunderstanding/missing something here or is the NuGet package manager not handling this correctly? Is there some quirk with the nuspec now being in the csproj file or maybe I'm supposed to add something in to make sure it dependency is properly specified?
Related
We create our installation packages with WiX Toolset. I'm trying to enable 4-digit product versioning (like 4.0.0.195, 4.0.0.196 etc). The problem is that when product is upgraded the previous version is not uninstalled.
I am aware of ProductVersion limitation. And my current approach to the problem is writing a C++ custom action. This action successfully detects the installed product, I have its upgrade code. The custom action is also capable of setting MSI properties through MsiSetProperty. But what do I need to do to force removal of the installed product?
Per this link I see that in MSI there is Upgrade table that I might have to modify. But how do I do it for running installation? MsiGetActiveDatabase gives a read-only handle. MsiOpenDatabase opens MSI files by path.
Am I going the wrong way?
Yes. You are going the wrong way. Use the first three parts of the ProductVersion so upgrades can work correctly.
I made a laucher application in c++ that use direct 2d and 3d. Now i making a installer for this. I followed microsoft docs and i made it but there is a issue.
I use 'Microsoft Visual Studio Installer Projects' extension to make that.
The issue is if i already installed my launcher with a previous installer msi file, if i rebuilt a new installer msi and try to run it it show me this error
This is the microft docs i followed to make this: https://learn.microsoft.com/en-us/cpp/ide/walkthrough-deploying-your-program-cpp?view=msvc-160
In the future maybe i need make a update for my laucher. It isn't good idea everytime need go to control panel, search and delete the previous application and install the new one manually.
Anyone know how can i make it automatic remove old version and install new one? Maybe there is a better way to create a installer?
Major Upgrade: In order to upgrade properly, you need to use a major upgrade so that your new version uninstalls the old one and then installs itself (this can happen in reverse order too: new version installed and old remnants deleted afterwards, but this is another story). There are further upgrade types, but stick to major upgrades for simplicity.
The message you are receiving is basically because you have a different package code for the new MSI, but not a new product code or version number (or just one of those problems). You need to get the settings straight.
Recommended step-by-step:
Set "RemovePreviousVersions" to True in the project properties.
In the same place: bump up your version number (one of the first 3 digits)
Answer yes when asked to change product code, or do so yourself manually.
Keep the UpgradeCode the same - it needs to be stable across releases.
Rebuild your setups. Clean out your box of old remnants before testing or test on a virtual.
Testing: Remember to simulate your full upgrade process from first version installed to the new one with different version numbers for a few core files and also try to add a few files and such things. Very important to verify.
Heads-Up: Before ending, it is standard procedure to warn about the potential limitations of VSInstaller Projects (shorter list form).
MSI Tools: Here is a short "review" of other MSI tools.
MSI Upgrade Types: Shamelessly stolen from the InstallShield help file (towards bottom):
I have an ASP.NET Core Web API Application, I was instructed to update the NuGet Packages, once I started upgrading, NuGet started throwing errors about missing dependencies, after going one by one (one depends on other that was not installed and that one depends from another 2 that were not installed and so it goes); I encountered the following error where I got stuck:
Detected package downgrade: Microsoft.EntityFrameworkCore.SqlServer from 2.2.6 to 2.2.4. Reference the package directly from the project to select a different version.
Below that error I see that "Install a Reference to Microsoft.EntityFrameworkCore.Abstractions 2.2.6 to solve the issue"
But when I try to do that, it throws:
"Version conflict detected, Install a Reference to Microsoft.EntityFrameworkCore 2.2.6 to solve this issue"
Of course this is a circular error is not giving me options, I tried to install version 2.2.4 and threw the same conflict error (but related to version 2.2.3 and so on).
This is Visual Studio Enterprise 2017, ASP.NET Core 2.1
I already tried adding true
To the .cproj file and did not work at all
I think you've gone down a rabbit hole here. The exception, in general, just means that your project is getting two references for the same package and one of those references is to a lesser version. That could happen for any number of reasons, but it generally boils down to two possibilities (or a combination of the two):
You've got different metapackages that reference the same package, and the metapackage versions are mismatched.
You've got one or more project dependencies, and those dependent project(s) use different versions of the same package/metapackage.
The stuff about "install a reference to Microsoft.EntityFrameworkCore.Abstractions" are usually red herrings. It's calling out the specific package reference version mismatch, but that doesn't mean that literally installing that package is the best approach.
The big thing is going to be metapackages, as these are basically just multiple packages rolled into one reference. The actual underlying packages and their versions are not directly referenced, but they're there, just as if you'd directly added the reference. As such, it's not always clear that two separate metapackages are actually using one or more of the same packages under the hood.
The best course at this point is to rollback your package reference changes. You've probably introduced more problems than you've solved. Remove any extraneous or superfluous references. For example, if you've got a reference to both Microsoft.EntityFrameworkCore and Microsoft.EntityFrameworkCore.Abstractions, remove Abtractions. It's easiest to do this by directly editing the .csproj file. Go project by project in your solution and pare back packages to only the ones absolutely necessary for your project(s). Hint: if you start seeing red squigglies in your code, you actually needed that one.
Once you've done this, upgrade all the NuGet packages for the entire solution all at once. Literally, right-click the solution and choose "Manage NuGet packages for the Solution". You should also check the "Consolidate" tab and ensure that there's nothing there, i.e. you're running the same versions of everything across all projects. Then, you should be good to go.
Today after updating our projects it seems Xunit.KRunner is no longer available on NuGet. We checked the Microsoft projects and it looks like they are using the xunit.runner.kre package. When trying to install this the xunit.assert assemly is failing to download from Nuget. Any suggestions to get this working? I am guessing that the versions are messed up.
Here are my nuget package locations:
I'm also using the beta2 version of the kre.
There is/was an issue with the new xunit.runner.kre and VS CTP 5. See below discussion:
https://github.com/aspnet/Testing/issues/65
xunit.runner.xre is available only on myget/vnext feed. Include that in the Nuget.config that you should be able to restore the package
By running on the beta2 kre you're then having mismatched dependencies. If you look at the versions of your xunit bits they're all beta3. I'd recommend upping your kre to beta3 to fix your issue (will affect which packages your app pulls in).
Also as a side note I'd recommend ensuring your nuget.org/api/v2/ feed is enabled (in the SS you posted it wasn't). There's currently an issue where it'll occasionally disable itself; has definitely made my life frustrating several times when things don't build :).
My Windows XP workstation at the office had several old versions of the Java JDK installed on it. Today I decided to install the newest Java JDK and uninstall the older ones. BIG MISTAKE APPARENTLY!
I don't understand why, but XP seems to think that one of the removed JDK installations is the one that it wants to use. Not sure if it is relevant, but it was JDK 1.6.0_13. I uninstalled it earlier using the XP "Add or Remove Programs" from the Control Panel. The JDK folder is gone (as one would expect) but apparently not forgotten. Here are the symptoms:
Eclipse will no longer start up and use the new JDK that I installed. Eclipse acts as if there is no JDK available on the system.
When I type java -version at a Command Prompt I get the following response:
Error: could not open `C:\jdk1.6.0_13\jre\lib\i386\jvm.cfg'
(Gee thanks. I never would have guessed that the uninstalled JDK could not be found...)
When searching around on the machine I found a system service named "Java Quick Starter" that is pointing to the removed JDK directory.
Now I know what some of you are probably thinking. He has a JAVA_HOME system variable pointing to the old location and/or has the old location in his PATH system variable. Not the case! There are no system variables that reference this old JDK and neither does my PATH. In fact, I have already defined a new JAVA_HOME for the new JDK that I installed this morning and added it to the system PATH. I was sure that would at least give me success from the Command Prompt, but no luck.
And in case you're wondering if I have rebooted after the install/uninstall/system variable changes, yes I have.
QUESTION
Does anyone know what I did wrong here? How do I purge these references to the uninstalled JDK from my system so it can start using the newly installed one?
EDIT 1
I checked the registry as duffymo suggested. There was some stuff under HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft that did not look right. An entry still existed for the 1.6.0_13 JDK that I had deleted, and a number of the newer JDK installs had entries here with their JavaHome attribute set to the path for the old 1.6.0_13 JDK for some inexplicable reason!
I uninstalled all of the JDKs on the machine, but still there is a remnant of the old 1.6.0_13 JDK in this registry section.
Also, a 1.6.0_21 JRE is still listed in the Add and Remove Programs list that gives an error if I try to uninstall it. That one is also shown in the registry and has a registry "JavaHome" key with a value that points to the no-longer-existing JDK 1.6.0_13.
Check the registry to see if something is hanging around there to point to the old JRE.
Look at HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft. You'll see Java Development Kit and Java Runtime Environment there. See what they say.
Now that you've found that the registry values are incorrect, I'd recommend either modifying them to point to the correct values OR remove them, uninstall the JDK, and reinstall.
You could also maybe try disabling the service from starting.
Copied from my repost of this quesiton on www.superuser.com:
https://superuser.com/questions/203143/cannot-install-java-jre-on-windows-xp-workstation-possibly-due-to-previous-faile
I tried CCleaner on the registry, but it didn't solve the problem. I was feeling pretty desperate at that point and decided to search the registry with regedt32 for instances of "jdk1.6.0" and delete everything that was obviously garbage. Any registry references to JDK/JRE instances that I knew no longer existed got deleted. Usually this meant deleting the whole key, but there were a few keys where I just had to delete an individual value/data pair. I rebooted after I was done performing meatball surgery on my poor defenceless registry.
DISCLAIMER: I don't recommend that anyone start messing with random keys in their registry as the primary way to solve a problem! This was my last resort before considering the option of re-imaging my workstation and re-installing EVERYTHING.
Having said that, this approach did solve my problem. I was able to install the JRE and then things like Eclipse started working normally once again. I next installed a JDK of the same version without incident.