I can confirm that its working for us now. Thanks!

Hi Dan,

i will try. But it will take some time. Log4j fallout comes first;)

Greetings

Here the log from the npm attempt (sensitive data removed):

0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli   'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli   'install',
1 verbose cli   '@*********/baseui@1.0.10'
1 verbose cli ]
2 info using npm@6.14.13
3 info using node@v14.17.0
4 verbose npm-session f37403ddb21d77d5
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 http fetch GET 200 https://proget:9443/npm/*********/@*********%2fbaseui 17ms (from cache)
8 silly registry:manifest no matching version for @*********/baseui@1.0.10 in the cache. Forcing revalidation.
9 http fetch GET 200 https://proget:9443/npm/*********/@*********%2fbaseui 277ms
10 silly fetchPackageMetaData error for @*********/baseui@1.0.10 No matching version found for @*********/baseui@1.0.10.
11 timing stage:rollbackFailedOptional Completed in 1ms
12 timing stage:runTopLevelLifecycles Completed in 1252ms
13 verbose type version
14 verbose stack @*********/baseui: No matching version found for @*********/baseui@1.0.10.
14 verbose stack     at pickManifest (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-pick-manifest\index.js:122:13)
14 verbose stack     at C:\Program Files\nodejs\node_modules\npm\node_modules\pacote\lib\fetchers\registry\manifest.js:43:18
14 verbose stack     at tryCatcher (C:\Program Files\nodejs\node_modules\npm\node_modules\bluebird\js\release\util.js:16:23)
14 verbose stack     at Promise._settlePromiseFromHandler (C:\Program Files\nodejs\node_modules\npm\node_modules\bluebird\js\release\promise.js:517:31)
14 verbose stack     at Promise._settlePromise (C:\Program Files\nodejs\node_modules\npm\node_modules\bluebird\js\release\promise.js:574:18)
14 verbose stack     at Promise._settlePromise0 (C:\Program Files\nodejs\node_modules\npm\node_modules\bluebird\js\release\promise.js:619:10)
14 verbose stack     at Promise._settlePromises (C:\Program Files\nodejs\node_modules\npm\node_modules\bluebird\js\release\promise.js:699:18)
14 verbose stack     at _drainQueueStep (C:\Program Files\nodejs\node_modules\npm\node_modules\bluebird\js\release\async.js:138:12)
14 verbose stack     at _drainQueue (C:\Program Files\nodejs\node_modules\npm\node_modules\bluebird\js\release\async.js:131:9)
14 verbose stack     at Async._drainQueues (C:\Program Files\nodejs\node_modules\npm\node_modules\bluebird\js\release\async.js:147:5)
14 verbose stack     at Immediate.Async.drainQueues [as _onImmediate] (C:\Program Files\nodejs\node_modules\npm\node_modules\bluebird\js\release\async.js:17:14)
14 verbose stack     at processImmediate (internal/timers.js:462:21)
15 verbose cwd C:\ApacheTomcat\webapps\ROOT\SCP\Sphere-Invoice-Interface\ui\InvoiceInterfaceMonitor
16 verbose Windows_NT 10.0.19044
17 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "@*********/baseui@1.0.10"
18 verbose node v14.17.0
19 verbose npm  v6.14.13
20 error code ETARGET
21 error notarget No matching version found for @*********/baseui@1.0.10.
22 error notarget In most cases you or one of your dependencies are requesting
22 error notarget a package version that doesn't exist.
23 verbose exit [ 1, true ]

Npm does not find it in its cache and a retry occurs which fails with: "No matching version found"

We have the same problem after we updated to ProGet 6. We can publish npm packages and view/download them in ProGet Browser UI totaly fine. But when working with npm console it is not showing up. The only thing that works is explicitly an IIS reset. After that it works till a new version is uploaded. The mentioned IIS cache setting is off. Restarting the ProGet service (not IIS) has no effect. So far Nuget and other feed types that we are using seem not be affected.

I think i found something out. Our packages are build on "portable" (the default i think for newer dotnet projs). When i set them to full or pdb-only, the initial push started to behave as expected. But debugging would only work on Windows systems? So i guess i have to stick to portable.

So i headed over to myget.org an started pulling some nugets that are not too shaby.

I tried out Autofac and they had the same issue (but after manual reindex it works). Than i tried OpenCover and they worked on initial push (no manual reindex necessary).

Than something strange came to my eyes. The "Age" seems a little bit weird.

Autofac:

path id age
lib/net5.0/Autofac.pdb 	50ea1af6-a55c-433e-a601-2d0528cc0f38 	-755459259
lib/netstandard2.0/Autofac.pdb 	3350fbd8-133a-4695-b62e-fb2b85da4f88 	-2023348432
lib/netstandard2.1/Autofac.pdb 	620be175-d8d9-4673-a212-b965212a4648 	-801437170

OpenCover:

path id age
Samples/x64/OpenCover.Simple.Target.pdb 	7f83029d-16ff-45c0-b3a0-3988d91dc336 	1
Samples/x86/OpenCover.Simple.Target.pdb 	6b13fb82-c89d-4e39-a581-62adce159717 	1
tools/OpenCover.Console.pdb 	6b9003c1-5b1e-4faa-8efb-cc4f72037ca3 	1
tools/OpenCover.Extensions.pdb 	e40ed889-d3d8-4831-af33-a2415b0d0818 	1
tools/OpenCover.Framework.pdb 	d55908b6-c044-4e4b-b167-23595170dae9 	1

So the age is something like "-755459259" for Autfac and "1" for OpenCover. Our own packges have also a weird age with a minus.

Thanks for the info. At least it gives me a hint that something is maybe wrong on my side.

We have several own Nuget packages in use and they all have this problem. I will try to find an external package/repo to produce a symbol package that should work.

I honestly dont know what i am doing wrong. Even the test Nuget that i send you is fairly simple. I have this issue when i build it localy on Windows 10 and from our CI servers (Jenkins/Linux). I am using dotnet build, pack and push commands in dotnet core context (3.1 and 5.0, but the issue was also before 5.0 usage).

Mail is out. I had to modify the package so that it can leave our company but i tested it again and the issue still persists.

Hi,

when i push a Nuget package that has additionally debug symbols i can consume them just fine and work with them. When i try to use the symbol server, VS cant find the symbols. I checked if they are indexed under the symbol tab (in ProGet) and they are not. After i manually reindex the feed everything works as expected. VS can find the symbols and i can debug. Works like a charm. Anyone else has this behavior? Did i missed something? Is this expected?

Some additional infos:

• ProGet Version: 5.3.18
• ProGet was on 4.x before i upgrade some time ago to 5.x
• i dont remember when exactly this behavior started (i just recently started again to debug our own nugets)
• i dont see anything suspicious in the logs
• a manual reindex solves it
• i created a new fresh feed and tested it out (uploaded a package (with symbols) manually over ui), same problem
• i waited to see if some job would index it, waited over the weekend. No luck.

Regards