I am getting error while restoring package from my Azure Artifacts Feed.
How I do is , I have one nuget.config file(which contains url for my Azure artifacts feed and credentials) which I am calling from nuget.exe from my build machine.
Problem is , From the same network's build machine this process is working fine. From another network's machine also packages are getting restored except one, for only one package I am getting an error here.
Error-
Errors in packages.config projects
Unable to find version '1.1.32.1' of package 'MyPackage'.
https://MyOrg:8080/tfs/MyProj/_packaging/MyFeed/nuget/v3/index.json: Error downloading 'MyPackage.1.1.32.1' from 'https://MyOrg.
56c70b71-9921-40e7-968e-1234567cfe4d/nuget/v3/flat2/MyPackage/1.1.32.1/MyPackage.1.1.32.1.nupkg'.
The HTTP request to 'GET https://MyOrg:8080/tfs/MyProj/_packaging/56c70b71-9921-40e7-968e-1234567cfe4d/nuget/v3/flat2/MyPackage/1.1.32.1/MyPackage.1.1.32.1.nupkg' has timed out after 100000ms.
What I tried -
Checked with Disabling parallel processing.
Able to browse feed's url from all the build machines(also from another network's build machine)
Checked nuget.exe version 3.5.0/4.1.0/5.5.1
Deleted all nuget cache and checked again.
Can anyone help with this ?
You can also try:
Use dotnet restore if your projects target .net core. See note here
Use the .NET Core task, which has full support for all package scenarios currently supported by dotnet, including restore, pack, and nuget push.
Check the feed and make sure it do exist valid 1.1.32.1 version of the package there.
Use Feeds I select here option to check if it makes any difference(I guess maybe this issue has something to do with your nuget.config file):
Related
We upgraded our version of IronPdf from 2021.3.1. to 2022.2.4887 in a .net core 3.1 web api and all is well in our local environments and on our deployed dev environment. But, when we deployed to our test environment we are now getting errors when attempting to create a pdf from html. I enabled IronPdf logging and get an error saying Invalid Deployment ...\runtimes\win-x64\native\IronInterop.dll
Does anyone have an idea as to what this may be? I have attempted completely clearing out the deployment location of the api and doing a fresh publish and I found one article saying that I should set a custom TempFolderPath, but neither of those made any difference in the error. I don't completely understand this error as the same dll is being used in both our local and dev environments, so I wouldn't think that the dll is corrupted in some way.
Working with IronPDF I did finally get a solution to this issue. The problem was that my test server didn't have the latest C++ redistributables, which evidently weren't required for the version I was using previously. There is now an article in their documentation that includes information on installing the redistributables from Microsoft as well as other troubleshooting steps for this issue: https://ironpdf.com/troubleshooting/failed-to-deploy-nuget-package/
Every time i'm opening a solution in Visual Studio 2017 which uses Net.Core SDK it restores packages. It happens all the time, even if i close the solution and open it again.
Why does not it keep a local track of what nuget packages are present on the machine?
Can i make it to behave more logically and first to check it locally for the package presence and to restore it only if it can not be found?
Question: How to prevent nuget from redundantly restoring packages after opening solution in Visual Studio 2017
There is currently no way to disable auto-restore explicitly. Check following thread for more details:
How do I disable restoring NuGet packages while starting the solution
The restore you are seeing there is Auto-Restore which will only run
on SDK based projects.
https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore#automatic-restore-in-visual-studio
There is currently no way to disable auto-restore explicitly but you
can disable restore itself. Note that this will disable all restore
(on build/rebuild & solution right click restore)
Besides, you do not need to disable it, check the another reason below:
Question: Can i make it to behave more logically and first to check it locally
for the package presence and to restore it only if it can not be
found?
What nuget is doing now is exactly what you want it to do. Check:
Forcing restore from package sources:
By default, NuGet restore operations use packages from the
global-packages and http-cache folders.
So, the restore you are seeing when you open the solution is just check if the packages exists in the global-packages, if not, then nuget start to restore the packages. If packages are exists, nuget does not execute the restore operation. And checking time is very short, about tens of ms. You don't have to worry too much about it.
Hope this helps.
We require help.
We are applying Service Pack 2 to AEM 6.1 and SP2 deployment failed with Error 500. Unfortunately we've started the AEM and startup failed due to missing bundles or in correct bundle dependencies. We restored AEM from backup a which we took before night but while starting we received below error.
Any help to recover the instance is appreciated.
* [FelixStartLevel] org.apache.jackrabbit.oak.plugins.nodetype.TypeEditorProvider Node type change for cq:PollConfig requires repository scan: org.apache.jackrabbit.oak.plu
gins.nodetype.NodeTypeDefDiff[
nodeTypeName=cq:PollConfig,
mixinFlagDiff=NONE,
supertypesDiff=NONE,
propertyDifferences=[
org.apache.jackrabbit.oak.plugins.nodetype.NodeTypeDefDiff$PropDefDiff[itemName=target, type=TRIVIAL, operation=MODIFIED],
org.apache.jackrabbit.oak.plugins.nodetype.NodeTypeDefDiff$PropDefDiff[itemName=source, type=MAJOR, operation=ADDED]
],
In general, whenever a node type definition is changed, OAK triggers a scan to ensure the consistency of the repository. AEM 6.1 SP2 upgrade has a few node type definition changes and depending on the size of your repository the full scan (which is basically an in-depth node traversal) could take a substantial amount of time (several hours).
The message you are seeing in the log is an INFO message and not an error. If you keep monitoring your logs, you will eventually see something like:
[FelixStartLevel] org.apache.jackrabbit.oak.plugins.nodetype.TypeEditorProvider Node type changes: [cq:PollConfig, cq:PollConfig]; repository scan took <time duaration>ms
The startup is slow and hasn't failed unless you see errors from repository scans or other causes. Post an error if you see one and it can be looked at.
You can also try running the consistency checks via oak-run tool to verify the repository state after the upgrade. Detailed instructions can be found below:
https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run
Note that this tool can work on offline repositories so you don't need a running instance to check for issues.
It is also recommended to install critical hotfixes and service packs using the crx-quickstart/install folder. Leave the packages in this folder after installation as they won't reinstall after subsequent startups but deleting some packages may uninstall them.
Hope this helps.
I am using SignalR with Redis backplane scaleout. Now, the Microsoft.AspNet.SignalR.Redis package has a dependency to StackExchange.Redis.StrongName.
Since I was already using Redis in my application, I have the StackExchange.Redis package installed.
When I install Microsoft.AspNet.SignalR.Redis and choose not to install the dependency to the strong-named package for Redis, my application stops working (the client doesn't connect to the server - it tries every method of connecting, falling back to longPolling, but fails).
The strange thing is that if I install StackExchange.Redis.StrongName (at this point I have both the strong-named version and the normal one - so I have duplicate identifiers for every type from Redis) - I uninstall the strong-named package and everything starts working. (even if the strong-named package doesn't have any dependencies).
My question - does the strong-named package contain some specific stuff that SignalR uses (and why does the application work after removing it?)
Thanks!
You probably have the strong name redis dll left in a bin folder. Do a clean build and see if it still works.
The solution is to move over the the StackExchange.Redis.StrongName package.
I previously installed a website on the server by running an msi package and everything worked fine. Now, when I try to run the same msi file (to Repair/Uninstall), I get a message:
When I click Cancel, I get the following message:
Anybody has an idea what happened and how it can be fixed?
I would recommend that you run the MSI with logging enabled. This can be done by using the /l*v C:\mylog.txt switch or by modifying the registry. The log will provide you with more precise information as to what is going wrong during the msi process.
The articles below describe how to enable logging and the logging process in more detail
http://support.microsoft.com/kb/223300
http://technet.microsoft.com/en-us/library/cc759262(v=WS.10).aspx
http://msdn.microsoft.com/en-us/library/aa372847(v=vs.85).aspx
Once you have the log you can use a set of MSI tools like the Orca installer database editor tool on the Windows SDK to correct any issues.
This is the link for Windows 7 SDK which contains the msi tools.
http://www.microsoft.com/en-us/download/details.aspx?id=8279
Sorry for answering my own question, but I found the problem and I want to share the solution:
After I installed the old version on the server, I changed the name of the msi file. Consequently, I could not run the old version to repair/update. I could not even install a newer version over the old version, as the installer needed the old msi to uninstall the old version.
When I changed back the filename of the old version, it allowed me to install the new version.
CONCLUSION: Don't change the name of the msi file after installation.