Hello Leandro, Feeds_GetLicenseUrls hasn't existed since 4.7.0. It's possible that the error you encountered was from a custom extension which is not compatible with 5.0. ProGet 5.0 uses the Inedo.SDK NuGet package instead of the Inedo.ProGet.SDK NuGet package, and loads extensions that end in .inedox instead of .progetx.

Thanks for letting us know; we've since fixed the regression in v5.0.7.

Hello Phil, This appears to be a bug where NuGet packages with no stable versions keep their first-uploaded version as the "latest". I've filed PG-1201 with a fix. As a workaround, uploading a version of the package with a version number that does not include a hyphen (with a lower version number than the actual latest version of the package) will make the latest version update correctly.

Thanks Dean, the images are available now.

First and foremost, an InedoAgent will respond to any request with the proper AES encryption token (like a password), so if you don't want BuildMaster talking to a server/agent, then don't configure a valid connection to that agent. Are you connecting your Standbox server to the same SQL SErver database? This is a big problem, don't do it... ** Never have two instances of buildMaster talk to the same database ** Are you restoring a database back up to sandbox? It's strongly not recommended, because of the problem you describe. The agents will be configured to talk to eachother. Instead,, when setting up a sandbox, create a representative and testable version of your applications and processes. /you'll never be able to get a "perfect test" (since you can't talk to exact same servers), so at best you should test the broad functionality instead of the connectivity.

The Execute SQL Operation will only capture output specitically printed to the host. To capture the output of select statements, you might want to use a tool like "isql.exe" instead, that prints the results of a select statement to the console.

That's not a known bug. It's really hard to say; the function should work, and an error should be logged if it's not deleting. You may find errors in Admin > Erros.

hi Markus, you should be able to put credentials in your Connector. Then you should be able to connect.

I have tracked down the root cause of this issue. NuGet feeds (but not NuGet (quirks) feeds) in ProGet 5 generate a list of symbols, but never actually put them in the database. The fix is filed as PG-1195 and will be coming in the next version of ProGet 5. It includes a button in the feed management page to re-index all symbols in a feed, and packages affected by this bug have a message with a link to the feed management page in the place where the list of symbol files would normally be.

It looks like this is just an oversight on our part, because the unlisted package is the latest version. I've logged this as PG-1194 and scheduled to fix in a maintenance release.

I would remove the "NuGet API Key" from your NuGet feed; that is a seperate thing from "ProGet API Keys", which makes it quite confusing. This is why it will be deprecated in v5. You don't need an API key; you can just publish using usename/[password.

Manage Pipelines cannot be scoped to an environment, because pipelines are not associated with an environment. They deploy to a series of environments. you can restrict deployment to environments. You can restrict editing of configuration file instances to a particular environment, and as long as that configuration file is associated with an environment.

Hello Clint, This SQL will copy any credentials that BuildMaster has but Otter doesn't to Otter. However, it will not work if BuildMaster and Otter use different encryption keys. You can find the encryption keys for BuildMaster and Otter in app_appSettings.config and in web_appSettings.config. The key will look like this in the file: <add key="Persistence.EncryptionKey" value="[encryption key is here]" /> INSERT INTO [Otter].[dbo].[Credentials] ([Environment_Id], [Credential_Name], [CredentialType_Name], [LegacyConfiguration_Bytes], [Configuration_Xml], [AllowFunctionAccess_Indicator]) -- Omit the line above this comment to test this before running it for real SELECT OE.[Environment_Id] ,BC.[Credential_Name] ,BC.[CredentialType_Name] ,[LegacyConfiguration_Bytes] = NULL ,[Configuration_Xml] = CAST(REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( CAST(BC.[Configuration_Xml] AS VARCHAR(MAX)), '<Inedo.BuildMaster.Extensibility.Credentials.BuildMasterCredentials Assembly="BuildMasterCore">', '<Inedo.Otter.Extensions.Credentials.BuildMasterCredentials Assembly="OtterCore">' ), '<Inedo.BuildMaster.Extensibility.Credentials.OtterCredentials Assembly="BuildMasterCore">', '<Inedo.Otter.Extensions.Credentials.OtterCredentials Assembly="OtterCore">' ), '<Inedo.BuildMaster.Extensibility.Credentials.ProGetCredentials Assembly="BuildMasterCore">', '<Inedo.Otter.Extensions.Credentials.ProGetCredentials Assembly="OtterCore">' ), '<Inedo.BuildMaster.Extensibility.Credentials.PrivateKeyCredentials Assembly="BuildMasterCore">', '<Inedo.Otter.Extensions.Credentials.PrivateKeyCredentials Assembly="OtterCore">' ), '<Inedo.BuildMaster.Extensibility.Credentials.UsernamePasswordCredentials Assembly="BuildMasterCore">', '<Inedo.Otter.Extensions.Credentials.UsernamePasswordCredentials Assembly="OtterCore">' ), '</Inedo.BuildMaster.Extensibility.Credentials.BuildMasterCredentials>', '</Inedo.Otter.Extensions.Credentials.BuildMasterCredentials>' ), '</Inedo.BuildMaster.Extensibility.Credentials.OtterCredentials>', '</Inedo.Otter.Extensions.Credentials.OtterCredentials>' ), '</Inedo.BuildMaster.Extensibility.Credentials.ProGetCredentials>', '</Inedo.Otter.Extensions.Credentials.ProGetCredentials>' ), '</Inedo.BuildMaster.Extensibility.Credentials.PrivateKeyCredentials>', '</Inedo.Otter.Extensions.Credentials.PrivateKeyCredentials>' ), '</Inedo.BuildMaster.Extensibility.Credentials.UsernamePasswordCredentials>', '</Inedo.Otter.Extensions.Credentials.UsernamePasswordCredentials>' ) AS XML) ,BC.[AllowFunctionAccess_Indicator] FROM [BuildMaster].[dbo].[Credentials] BC LEFT OUTER JOIN [Otter].[dbo].[Credentials] OC ON BC.[Credential_Name] = OC.[Credential_Name] LEFT OUTER JOIN [BuildMaster].[dbo].[Environments] BE ON BC.[Environment_Id] = BE.[Environment_Id] LEFT OUTER JOIN [Otter].[dbo].[Environments] OE ON BE.[Environment_Name] = OE.[Environment_Name] WHERE OC.[Credential_Id] IS NULL

Ok, I see that my issue is exactly what is described in https://inedo.com/support/questions/7450. Thanks for the quick reply. I'll update to v5 when it comes out of beta.

Never mind, found the 5.0 beta :-)

I've logged PG-1192 as a change to sort alphabetically, with exception of latest.

If it's an "active" DR (i.e. the servers are running, it's used for testing purposes, etc) then each server would require a license. If it's something like, a snapshot of a server (and isn't running... but could be as soon as production goes off), then you can use the same license. It's similar to a lot of Microsoft (and other vendors) licenses for non-production environments.

This was caused by a connector that was returning a 500 server error. Inedo might want to look into better handling of these errors.

This is by design, and works fine for 95% or more of the use cases. The major benefit to in-process execution is performance; a new process/environment will often take longer to initialize the entire script to run, especially depending on the modules installed. This makes use of lots of small or inline scripts (like a $PSEval(...)) impractically slow. The downside to this is, is that a "bad" PowerShell script can leak memory and cause the overall agent process to balloon. Of course, process environment variables are also shared... but this is much less common, as it is considered an anti-pattern to ps development. However, many scripts are directly translated directly from Linux bash, so the pattern comes through. Anyways, we plan to solve this (and other shared-process problems) by allowing for agent process isolation. Basically, you will be able to do something like with isolation {...} and then all agents would spin up a new process to execute whatever is contained in the block.