Hi @p-boeren_9744,

I did receive the email, thank you for that. This mostly confirms my thought. There is still one issue, but I think it has to do with this package being downloaded anonymously first prior to adding login information to the NPM client. This fix is being tracked in ticket, PG-2059, and is scheduled to release on Friday in ProGet 6.0.5.

Thanks,
Dan

Hi @darkbasics_6739,

We found the issue and the fix will be released on Friday in Otter 3.0.17. This looks to be a regression from our .NET 5 conversion for our Docker image and tends to only affect specific operations. It just so happens that our demo PowerShell script and our Verify Hotfix example uses the features that this affects.

Thanks for catching this for us!

Thanks,
Dan

Hi @hwittenborn,

You are using the correct username. When using a username/password with an API key, the username should be api. Would you be able to share your configuration for the API key? It sounds like there is something incorrect in its settings.

If your user account has access to push packages/images to ProGet, could you try using a personal API key? When using a personal API key, you should still use the username api.

Thanks,
Dan

Hi @lockhead,

I think I see what the issue might be. Would you be able to capture the requests made from NPM to ProGet using a tool like fiddler and send them over to us? You can send the requests to support@inedo.com using the subject prefixed with [QA-706] . This would help greatly to confirm my thoughts.

Thanks,
Dan

Hi @darkbasics_6739,

Thanks for verifying that for us. Are you using the InedoAgent on the remote server or the PowerShell Agent? If you are running the InedoAgent, what version do you have installed? Also, could you try running it again? I have seen in some instances the download of the Scripting extension on the remote machine takes a bit longer and causes a similar error. I have found that typically this is resolved by the second Server check.

One last check, can you please verify what version of the Scripting extension you have installed? You can find that by navigating to Administration -> Extensions (Plug-ins)

Thanks,
Dan

Hi @darkbasics_6739,

What version of Otter are you running? Also, do you have it installed on Linux (Docker) or Windows? We had this issue with an older version of Otter when running on Linux (Docker), but it was fixed in Otter 3.0.14.

Thanks,
Dan

Hi @v-makkenze_6348,

Can you please share your IIS configuration settings that you have used? Can you specifically include any caching settings you have as well?

Thanks,
Dan

@scusson_9923 said in How to create an Asset Directory subfolder via the API:

https://docs.inedo.com/docs/proget-reference-api-asset-directories-api

Hi @scusson_9923,

I think the issue is that you are missing the -X in your curl command which is making curl think the URL is POST instead. Could you please try the following command:

curl -X POST https://<ProGet_server>/endpoints/<asset_dir>/<new_dir>/ --user <user>:<password>

Thanks,
Dan

Hello,

I believe the issue is because you have Windows Authentication enabled in IIS. Currently active directory authentication and integrated authentication (windows authentication) is only available in paid editions of ProGet. Please try disabling Windows Authentication in IIS and see if that fixes the issue.

Thanks,
Dan

Hi @kurt-burri_8500,

I think you are looking for our [Package Consumers] (https://docs.inedo.com/docs/proget-packages-package-consumers) feature in ProGet. Unfortunately, the automated way of doing this requires a paid version of ProGet, but you can manually add the consumer records. The automated way would be to run our pgscan tool against the source code and it will record a package consumer record on each of it's dependencies.

This feature will be more helpful going forward, so it's not exactly your use case. If you have access to the source code, you could either use a tool like Agent Ransack to search the contents of files for that package Id or fork our pgscan tool and modify it to scan through your projects and output which ones are consuming that dependency.

You could also try to use the feed APIs that the client tools use to walk the packages and look for dependencies, but there is not much guidance I can give there (especially since each feed type differs greatly) and this solution can get pretty complex pretty quickly.

Hope this helps!

Thanks,
Dan

Hi @kurt-burri_8500,

Could you please give us a little more context to this? Currently in the ProGet UI, the dependencies for a package will show on the Dependencies tab for the package version you are looking for. Are you looking for something different than that?

Thanks,
Dan

Hi @falk-winkler_2111,

Thanks for following up and letting us know this is resolved now. Can you please post what your final solution was?

Thanks,
Dan

Hi @jev_1362,

The file should be saved on the server in the storage path. Can you check and see if that file exists locally on the server? You can find the storage path for your asset directory by navigateing to Assets and then clicking the pencil to the right of the asset directory. Then click the Storage & Retention tab and you will see your storage path there.

Also, do you see any errors int eh diagnostics center when you try to download that file?

Thanks,
Dan

Hi @lukel_3991,

I think we have two different issues that are happening here. The first one it seems to not be synchronizing over the extensions. What version of PowerShell do you have installed on your remote server and the otter server? The PowerShell based agent-less servers connect using PSRemoting over WSMAN. Could you please try to connect to your remote server using Enter-PSSession in PowerShell on your Otter server and try to run some commands to make a temp folder and write a file to it using the same credentials Otter users to connect to that server? It almost feels like there may be a permissions issue.

The other issue seems like their could an issue with your OtterScript itself. Would you be able to share the OtterScript you are trying to run?

Thanks,
Dan

Hi @falk-winkler_2111,

Can you please try setting the Web.BaseUrl in Administration -> Advanced Settings to http://packages2.test.plano and restart your container? This will tell ProGet that the expected local URL is http://packages2.test.plano.

Thanks,
Dan

Hi @tcddpmonqxvfmiuyla_2318,

No problem, thanks for updating with what you found the problem to be.

Thanks,
Dan

Hi @paul_6112,

What are the hardware (or virtual hardware) specs of your server?

Thanks,
Dan

Hi @forcenet_4316,

Thanks for finding this for us. This looks to be a regression due to our recent API key changes. We have fixed this in our upcoming ProGet 6.0.2 release that is due out on Friday. These fixes are tracked in PG-2033 and PG-2034.

Thanks,
Dan

Hi @ashah_4271,

In summary, >> is SWIM syntax for OtterScript to create a string literal that allows multi-line strings. You could also use set $indexName = $PSEval('(Get-Date).AddMonths(-1).ToString("yyyy.MM.*")'); because that PowerShell is a single line and only has double quotes in it. I find the SWIM syntax works a bit better when embedding PowerShell inside of Otter Script because it removes risk when using single or double quotes within PowerShell. This is what I mixed up the first time. Simple PowerShell can normally use implicit string literals in the $PSEval function, but since there are double quotes, that breaks implicit string literals.

You can learn more about string literals in OtterScript in our Strings & Values documentation.

Thanks,
Dan

Hi @ashah_4271,

I'm not sure why this syntax error is happening, but I have a work-around for you. Can you please try:

##AH:UseTextMode


# Call DELETE on ElasticSearch
with retry = 3
{
    set $indexPSScript = >> (Get-Date).AddMonths(-1).ToString("yyyy.MM.*") >>;    
    set $indexName = $PSEval($indexPSScript);

    Get-Http $elasticUrl/$indexName
    (
        Method: DELETE
    );
}

Thanks,
Dan