There used to be an example in there... not sure what happened to it.
Anyway, there is an equivalent example in the Otter documentation: https://inedo.com/support/documentation/otter/reference/templating
Note the Apply-Template operation handles all the replacements / captures all configuration variables by default, while also allowing for other values to be injected if necessary.
Did you by chance save a copy of the installation log or submit an error report (we didn't see any come in recently)?
A 500 error is usually the result of a failed license key request, but if this is an upgrade it shouldn't perform that step.
With the ^ and $, that would mean the entire contents of the file must be IDString=whatever, is that the case here? If there is anything before or after that text it would never match.
The installer sets it to: SQL_Latin1_General_CP1_CI_AS
Hello Rickard,
Both the C# implementation and the Go implementation from https://github.com/Inedo/upack use the system-defined HTTP proxy.
Hello Chris,
1.0.0.0+meta is not a valid SemVer2 version number because it contains a 4-part base version number.
1.0.0+meta would be valid.
1.0.0-0+meta is also valid as long as the number in the prerelease section does not have extra zeroes before it. That is, 1.0.0-01+meta is not a valid SemVer2 version number.
The 1.0.1 version of the Chocolatey extension released a week ago should be compatible and loads on our own production instance. Do you maybe have multiple Chocolatey extensions in the \Extensions directory?
Thank you for the report - it appears the uninstaller is relying on a configuration value that does not exist; the uninstaller will be fixed in v5.0.8.
For reference, here is a quick summary of what the uninstaller does:
%ProgramFiles%\ProGet directoryHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ProGet hive from registryThis will be fixed as part of PG-1204 in v5.0.8 - due out early next week.
Your analysis is correct - the issue is related to packages missing SHA1 hashes in the ProGet databases; at some point packages were able to be added without them. We have updated the migration process internally to perform them if they are missing, and this fix will be included in the next maintenance release. Here is the tracking issue:
https://inedo.myjetbrains.com/youtrack/issue/PG-1203
We should have a maintenance release out to address this by early next week.
Apparently this "works" if you do:
IIS::Ensure-AppPool Test
(
Runtime: "",
Enable32BitAppOnWin64: true,
Pipeline: Integrated
);
Might be better to do something like:
set $NoManagedCode = "";
IIS::Ensure-AppPool Test
(
Runtime: $NoManagedCode,
Enable32BitAppOnWin64: true,
Pipeline: Integrated
);The issue is related to packages missing SHA1 hashes in the ProGet databases; at some point packages were able to be added without them. We have updated the migration process internally to perform them if they are missing, and this fix will be included in the next maintenance release. Here is the tracking issue:
The issue is related to packages missing SHA1 hashes in the ProGet databases; at some point packages were able to be added without them. We have updated the migration process internally to perform them if they are missing, and this fix will be included in the next maintenance release. Here is the tracking issue:
The issue is related to packages missing SHA1 hashes in the ProGet databases; at some point packages were able to be added without them. We have updated the migration process internally to perform them if they are missing, and this fix will be included in the next maintenance release. Here is the tracking issue:
As of the current version (5.0.7) this is not possible since the keys are required. We will investigate further; if this type of connectivity is possible via the Amazon SDK we will consider adding it.
Here is the tracking issue: https://github.com/Inedo/inedox-aws/issues/2
ProGet does not distinguish requests based on http or https (that's a different layer), so there is an error somewhere else in the stack. Are there any relevant logs from PowerShellGet?
I believe there was a fix for this (issue: BM-2392 - FIX: Variable bulk edit for releases and release packages checks for Admin_ConfigureBuildMaster task instead of Releases_Manage) in v5.6.9
The promotion API endpoint does not use a NuGet API key, it uses a ProGet API key. It is unfortunate that the terminology is similar, but feed endpoints are handled independently from ProGet API endpoints, so creating a ProGet API key will not interfere with normal dev use of the NuGet feed.
You need to create an API Key in the Admin > API Keys section, and that API key will only be used for ProGet API endpoints (i.e. package promotion, package deployment, and the future "feed management" API).
Support for portable PDBs is currently an "open issue", and our initial research found that metadata information was undocumented, however since then it has been: https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PortablePdb-Metadata.md
Unfortunately at this time we don't have a timetable for if or when this gets implemented, but it is on our list.
The ProGet server doesn't modify packages, except to strip embedded symbols and source code if that option is enabled on a feed. It certainly doesn't modify a package such that the folder structure is flattened.
Are you certain the package isn't flattened on the server, and in addition to that, actually being downloaded from ProGet at all (versus the NuGet cache or something like that)?
Just to clarify, .NET PDBs with "full" debugging information (i.e. Windows PDB format) are supported, it is just .NET "portable" format that is currently not supported.
Support for portable PDBs is currently an "open issue", and our initial research found that metadata information was undocumented, however since then it has been: https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PortablePdb-Metadata.md
Unfortunately at this time we don't have a timetable for if or when this gets implemented.
This was a regression: https://inedo.myjetbrains.com/youtrack/issue/PG-1085
We will have a maintenance release out today to fix this.
Don't call the SOAP methods directly; that's not supported, and the communication protocols can change in maintenance versions since it's not part of the SDK.
The best way to do this would be using the Util.Agents::CreateAgentFromId method. This will return an AgentBase instance.
Once you have that, you can invoke the GetService<T>() method (with IRemoteMethodExecuter as T), and then run code on the agent with the IRemoteMethodExecuter::InvokeMethod) method to get any information about the agent you'd like.
There is also AgentBase::GetAgentStatus) method, but that's not as easy to interact with since you need to construct a context to determine if the agent is considered outdated.