Hi @ashah_4271 ,

We could definitely improve our documentation in this area, but let me explain a few things...

$ApplicationName are $PipelineName contain the name of the application and pipeline in context. What this means is that, if an OtterScript is running within a build deployment, then it will be the name of the application, and the pipeline that the build is being deployed in.

Your custom build trigger OtterScript is running within an application, which means $ApplicationName will be whatever the name of the current application is. However, it's not running within a pipeline, so $PipelineName will be empty.

Long story short, you should only need to change $PipelineName to be the name of the pipeline you wish to use.

All that said, I don't know why Pipeline is required, when there is a default release template. So this can be an area of improvement in that operation as well :)

Please let me know if this is helpful, and then I will try to log an issue to fix/improve on our ends

Cheers,
Nanci

Hi @mjc_4927 ,

This was a regression in the Free Edition of v7 due to some internal library upgrades, but is now fixed as BM-3734 - it'll be in the next maintenance release :)

If you're interested in a patch/pre-release version, let me know and I can share it.

Cheers,

Nanci

Hi @csi_lund

We recently updated our documentation, can you take a read at Symbol and Source Server in ProGet?

Hopefully it helps explain things, but a couple things that are jumping out

• the /symbols/<feed-name> end point is intended for Visual Studio; you can't push packages to it, and will need to push to /nuget/<feed-name>
• if you want to use a single feed, then you need to make a single package by setting the DebugType property on your project file to embedded

Please let me know if I can clarify, so then we can improve our docs as well :)

Nanci

Hi @paul-reeves_6112 ,

That might be a bit more effort that it's worth (i.e. to proxy those external icons through BuildMaster), but something we can consider depending. Usually the client browser is not behind a restrictive proxy like that.

But most importantly... you can definitely point to your own template gallery. Once you do, you'll be able to publish your own templates under Application Settings.

You can also delete the Templates package source. It'll just give a warning on that page that it's not there, and give you a button to recreate it.

Cheers,
Nanci

Hi @Stephen-Schaff,

The renewal contact at your organization should have been receiving emails about 60 days ago, and then someone was supposed to be manually following up... but something clearly fell through the cracks. I already escalated it internally.

But not to worry! In a case like this, please just go to my.inedo.com, and request a 30-day trial license key. It has all the functionality of ProGet Basic, so your service won't be interrupted at all.

Changing the expiration warning in the software to 30 days is really good idea to prevent problems like this, so I'll request that as a feature internally :)

Cheers,

Nanci

Thanks @harald-somnes-hanssen_2204 !

This seems like a low-risk way to handle this going forward. We'll track this via PG-1924; note it's currently planned for the next maintenance release, so hopefully it'll be there soon!

In the meantime, if you've got a ton of vulnerabilities, we could help construct a database query to help with a one-off purge. But it might be easier to just click away, too

Thanks for reporting this regression! It appears to be related to some kind of refactoring.

I've logged it as OT-411 and we are targeting fixing it in the next release.

@pete_4689 you can configure Security and Access Controls to restrict which users have the Overwrite Package, Delete Package, and other privileges

@brett-polivka thanks

So, this may have been a regression due to a recent change to the Azure extension. Can you rollback to Azure 1.9.0 by manually installing it?

@Stephen-Schaff

I think cc/ @rhessinger can correct me if I'm wrong, but you should be able to just rollback only the the InedoCore extension to 1.7, where we used the older version of the AD libraries.

You can do this by downloading and manualy installing from here: https://proget.inedo.com/feeds/Extensions/inedox/InedoCore/1.7.12

@brett-polivka I know that there were some recent changes to these extensions; what version are you using of ProGet and the Azure extension (Admin > Extensins)?

Hi @kunal-bhujbal_8395 ,

You can ignore these messages.

.js.map files are used by Chrome's debugging tools, and may be requested by browsers that have debugging/development mode enabled.

ProGet does ship with .js.map files, and thus makes an error (404) if these files (or any others that ProGet does not have) are requested.

In a future version of ProGet, we will not log error messages when .js.map files are requested

Thanks,
Nanci

hey @jerome-jolidon_1453

Thanks for confirming about the versions. There was a change in ProGet 5.3.9 that might have fixed this:

• PG-1789 - FIX: Connector filter rules not working on NuGet feeds

But if it's not working on 5.3.17, then it must not have helped. So from here, we'll try to reproduce this and let you know the results.

Please stay tuned!

Cheers,
Nanci

Hello,

We're definitely keen on improving the documentation!

What version of ProGet are you using? In ProGet 5.3, it should involve...

1. navigate to the "Manage Feed" page.
2. select the "Connectors & Replication" tab.
3. select the desired connector name.
4. click "Add Filter," enter @microsoft/ and select "Block."

note this requires a paid Proget license.

Cheers,
Nanci