Posts made by atripp

Here are two posts that might help at least show you where to poke around:

https://inedo.com/support/questions/9293

https://inedo.com/support/questions/4092

If you can identify more specifically what the issue is, we can try to look for a fix!

Hello Damian,

I believe this is due to ILIB-60, which is caused by a bug in Mono.

Please carefully follow the Getting Started with NuGet Feeds in ProGet and Visual Studio tutorial.

You need to use the API endpoint URL (shown to you within ProGet's Feed page), not the URL that you at the top of your browser. The /feeds URL is intended for use by a web browser, and the /nuget URL is used for an API (i.e. Visual Studio).

I'm sorry but I'm not understanding what you mean by "queues" or "hangfire"...

There was a UI change; these are listed under "Containers" in the top UI.

Please note that retention policies are a paid feature. Although rules can still be configured in the free edition, they are always executed in dry run mode in ProGet Free.

In addition, when multiple options are specified, then only packages that meet all of the selected criteria are considered.

Please review the retention rules for more information

Otherwise, the best place to look would be the retention logs, to show you what packages were considered.

There have been no changes to the way our products connect to databases in many years, so this is unrelated to an upgrade.

However, it seems to be some sort of indication that SQL Server must be overloaded, or a network problem. This can typically be diagnosed / reviewed by the SQL Server DBA, who can see incoming connections, and which queries are taking too long, etc.

But in my experience, just restarting the server you have SQL Server installed on fixes it like 80% of the time.

You can use an API key: https://github.com/inedo/upack#push

Basically just use "api" as username, and the key as the password.

In this case, you can use the execute command line operation; please see Executing a Command Line Utility During Deployment in BuildMaster

Hello; this errro means that OTter can't connect to the database. Maybe the connection string changed?

I would check the database connection string in Otter's configuration file.

Maven indexes are for search only, and don't have any sort of sensible ordering, so you won't see packages like you would on npm feeds.

Please refer to KB#1161 for how to update to TLS 1.2

Based on that error, it sounds like your user account doesn't have dbo access to the database? This will be required to install/upgrade ProGet.

Hello Love,

It seems Maven feeds are missing support for caching connector packages. I've filed this as PG-1411.

Can you share the name of your docker image and docker feed?

Can you provide a specific example of a public package (on the official PowerShell Gallery), and then expected and actual results in ProGet?

Please disable the "Overwrite Package" permission in Admin > Tasks.

Then, you will get "Package Already Exists" error

In BuildMaster v6, there is an operation that you can use to set these:

Set-ConfigurationVariable(
    Variable: <text>,
    Value: <RuntimeValue>,
    [Application: <text>],
    [ApplicationGroup: <text>],
    [Deployable: <text>],
    [Server: <text>],
    [ServerRole: <text>],
    [Environment: <text>]
);

But, you said "We do use integrated auth in IIS" ?

If it's configured in IIS, then Docker won't be able to access the page/api. The client must support integrated authentication, which NuGet, web browsers, etc., do.

I'm afraid you can't use Integrated Authentication with Docker.

The client simply doesn't support it, which means IIS will always challenge with 401 prompts. A work-around to this is to set up a separate IIS Site (pointing to same directory) that doesn't have integrated auth configured.

Batch files need to be executed by "cmd.exe". Instead, you can directly execute a ".cmd" file.

There's really no difference between the versions as far as performance is concerned.

At first, try to determine why it's slow; a very common cause is connectors are broken or slow. Disable those, and see if it helps.

Try to see what queries are slow. API vs WebPages, search, etc. That will start clueing into the next area to look.

If you can share more data as what you find, we can provide more specific advice on where to look

Sorry, I misunderstood it myself and responded too quickly.

You're right, the OtterConfiguration_Key points to a DSC Property. It's not an alias, like I had assumed. But looking closer, I see that it is.

It seems this would require a feature/change request to fix; might not be so bad, but I'm not familiar enough w/ it to be certain.

If you're finding that you're having trouble with specific versions, please provide a detailed reproduction case with a specific package, and the specific steps you took; this way we can investigate it.

We do not provide a migration utility or tool, but if you create one we would be happy to share it with the community.

This is not a known issue, and is unrelated to the upgrade, the v3 url, etc. So, it must be some problem on your server with being able to connect to nuget.org

See: https://inedo.com/support/tutorials/proget/getting-started-with-nuget-feeds-in-proget-and-visual-studio

You should really be using the Ensure-RegistryValue operations for this, because it will do the exact same thing while being easier to maintain and visualize.

The Otter_ConfigurationKey must be unique per configurable item on the server. So, in this case, you should make a string based on the registry key+value. You can use the full key+value, or perhaps something like this:

PSDsc Registry
(
  Otter_ConfigurationKey: SecurityZones3_2100,
  Key : "HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3",

  ValueName : "2100",
  ValueType : 'Dword',
  ValueData : "3"
);

I totally agree! Thanks for pointing this out.

I've filed this is a bug report (OT-254), so it will get fixed in a future maintenance release

You can use $PSEval for this pretty easily:

set $a = 2;
set $b = 3;
set $c = $PSEval($a + $b);

You can do this with default values.

template Check_Version<$App, $Role=default>
{

}

And then test if it's the default value to see if it wasn't passed in

Soon --- this is a known issue, but we are in the process of resolving it; please see InedoCore#96

This is a known issue, but we are in the process of resolving it; please see InedoCore#96

At this time, the only thing we're aware of that can cause "Could not resolve function" is that the function has not been loaded by the service. Functions are stored in extensions, and Split is stored in Inedo Core extension, so this would actually cause all sorts of errors.

I created an issue (BM-3255) to give a warning if this extension is not loaded. But please restart the service, check for extension load errors in the message center, and try again.

Restarting the service would be the only way to resolve this, since extensions are loaded at service start.

The error message is coming from within the network stack inside of ASP.NET's hosting components, and errors like this tend to indicate problematic underlying infrastructure, such as drivers, hardware/memory. They are often quite rare and not reproducible, and thus can be difficult to diagnose or debug.

The Integrated Web Server was not designed to handle problematic infrastructure, and as such will simply crash when receiving certain "impossible" scenarios from the network stack. Certain errors are not safe to try/catch (because they imply a corrupt process memory state), which is why they are done.

If you are finding "service autorecovery" not enough, then you should switch to IIS hosting. IIS is very robust, and uses a worker process model and can handle a lot of these underlying problems. When a worker process crashes (which it will do in the same scenario -- unsafe exceptions), IIS will spin up a new one almost instantly.

This was a result of a imcompatable script with 2005, but it has been fixed as of 5.1.11. We are also displaying warning if you're using unsupported version of SQL

We are only aware of that message occurring in the two cases I mentioned, and haven't had reports of the contrary. From here, please use a tool like Fiddler or Wireshark to identify the exact request/response patterns that are happening. You can see the authentication headers sent, and it's possible there's a typo or something in a name or password.

We take problems very seriously, but we need to prioritize where to spend engineering resources tracking down problems. This was a edge case that we could not reproduce, and had a very minor impact, and only affected a very small number of free users with a very specific configuration; a free user was able to track down the underlying cause and we fixed it.

Hi,

the script who is stored in a global module

##AH:UseTextMode
module ParseURL<out $JsonFile>

{

set $URL = $DEPLOYABLE_URL;

set $PATH = $DEPLOYABLE_PATH;

set @MYLIST = @();

Log-Debug Split URL /;

foreach $DATA in @Split($URL,"/")
{
    # Log-Debug $Data;
    set $DATA = $Trim($DATA);

    if $DATA != ""
    {
        set @MYLIST = @ListInsert(@MYLIST, $DATA);
    }
}

......

Sometimes, it works, but the major part of the time I have the error resumed above.
I found nothing in the diagnostic center et nothing in the event viewer of the widows server.

Does exist other logs somewhere ?

Kind Regards

You can reset the Admin user account password by stopping the ProGet Windows service, then running ProGet.Service.exe and selecting the "ResetAdminPassword" option. Make sure to restart the Windows service when finished.

Can you give us a little more context? Like, what is your OtterScript overall?

One possibility is that the INedoCore extension had a load error, though I suspect you'd have another problem if that were the case.

Hello,

I've added an ExitCode output parameter to the SHCall operation.

You can download a preview build of the extension from here: https://ci.appveyor.com/project/Inedo/inedox-linux/build/1.0.3-CI.7/artifacts

Currently assets do not have any user-definable metadata like this, I guess because that would make them a lot like packages? Assets also aren't intended to be like a "SharePoint replacement", which is why we don't want to put a lot of extra features like versioning, etc. These are also hard to replicate, etc.

That being said, we are open to changes, so please consider using the Feature Request Process. Note that, we also want to evaluate "why" and "how this would be used", and that's part of the feature/change process.

Thanks.

FYI: Retention policies should be ignored on free versions. But UNKNOWN does indicate the service user; so it's likely a retention policy job (which is run as part of feed cleanup).

You can see the logs of those, and maybe see some more info...

There is a task attribute called "Delete Package". Just make sure you have a Task that has that attribute. You can see more info about it here:

https://inedo.com/support/documentation/proget/administration/security/creating-tasks

ProGet most definitely does not "lose package" on an upgrade, so there must have been some sort of configuration change, either in the ProGet software (retention policy, package store), or external to the software (files deleted from disk).

It's highly unlikely that this configuration changed as part of the upgrade, particularly from those versions. Most likely, your database backups just happened to be dated from before the upgrade because the installer will auto-backup for you; so, the upgrade is really a red herring. You can search ProGet's audit logs to see if anyone in the software deleted them.

But regardless, if the package files are gone, and you don't have them backed up (the installer will not do this for you), then they are gone. There's nothing you can do, so I think your idea of searching for fragments from user caches, and then uploading those, is the best you can do.

NOTE: Unless you explicitly configured a retention policy for ProGet to delete files, the software will not delete these files on disk. Even when you delete a feed or uninstall the software, the package files remain. We do this for safety purposes.

Please make sure to read our backup and restore instructions.

Definitely not, they are on the low-end of the medium size... and just to be clear you shouldn't be calling dbo.Dashboards_GetDashboardInfo with more than 10 packages. It's only designed/tested for 0, 1, and 10.

Based on the table sizes and distribution, there's no reason it should be performing so slowly. Actually it works fast even on instances with 100x the packages that you have.

Maybe there's something else with your data that we can't see based on the tables you sent us. You should be able to view/edit the code of the procedure and underlying database views; perhaps you can find something by investigating the queries and data relationships?

Without seeing your log, I really don't know. But in this case...

WARN : 2018-02-21 22:37:21Z - ID: 107;	Name: BUILD-SOURCE;	Scope: Release

We have a legacy release template variable called "BULID-SOURCE". This will only show up in an application's settings page, it will not show up under global.

So how can we find the application? well, if I run this query, SELECT Scoped_Application_Id FROM VariableDeclarations WHERE VariableDeclaration_Id=107 I can find the application id. From there, I can enter it in the navigation bar, and find the variables.

Yes. But hmm ... maybe it's a disabled application? You should be able to find those in the VariableDeclarations table; those IDs refer to those.

These Legacy Template Variables (Release, Build, Execution, Promotion) are defined at the application-level, not at the system-level.

If you View Full Log, you should be able to find a block that looks something like this:

WARN : 2018-02-21 22:37:21Z - Legacy template variable declarations found:
WARN : 2018-02-21 22:37:21Z - ID: 107;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 92;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 108;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 109;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 111;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 112;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 113;	Name: BUILD-SOURCE;	Scope: Release

If that's not enough information to locate, you can look directly in the SQL Server Database to find out.