@yakobseval_2238 thanks for letting us know, I just updated it!

Hi Ryan, Sorry for the delay in getting back to you - we're planning to add this to ProGet 5.2, which currently has a release date of April 11. It should be included in Inedo SDK 1.1.2 (see tentantive spec here). Does that look like it will cover your situation?

I'm afraid I don't really understand the requirements for what you're trying to accomplish... Here are the differences between the two extensibility points: A Package Filter allows all locally-stored ProGet packages to be filtered from being shown in feeds by additional logic. A Package Access Rule Allows for rules to block downloads of packages based on additional logic. The Package Access Rule is used by the Whitesource extension, so you can reference how that works. We don't have any publicly available uses of Package Filters; it was incorporated for a very specific usecase with publicly-available feeds.

You can actually put a full commit ID in the Tag field (which actually supports any refname)... I'll have someone put a note in to change that in the operation.

Thanks for the feedback. The HttpModule was not the cause. I just had to configure the NuGet.config credentials correctly in %ProgramData%\NuGet\Config\NuGet.Config, which is machine wide rather than user specific. I will distribute this configuration to all developer machines using an Active Directory Group Policy.

You should be able to reference your library from your custom extension. You just need to make sure that it and any other dependencies are either included in the .bmx file or are installed to the system GAC. BuildMaster doesn't use EF, so there shouldn't be any version conflicts there.

Unfortunately not, but this would be a great place to post it if you are able to get it working! :) But before you do that, check under Advanced Settings to see if modifying the Base Odata URL field will solve the problem you're looking for.

Generally, load errors are logged to the BuildMaster error log within the software. You could also get live log messages by following this article. Periods in the assembly/file name are allowed, so that must have been unrelated. It's also worth double-checking the extension overview page which will show the load errors, but they don't immediately jump out: [image: EDJnd0T.png] For additional troubleshooting with regard to extension loading: make sure to restart both the BuildMaster Windows service and web application service or IIS application pool once the file is added to the Extensions path make sure there is a BuildMasterAssemblyAttribute specified in the project (normally in AssemblyInfo.cs) the project is targeting the v4.0 or v4.5 version of the .NET framework the file name, the assembly name, and the containing .bmx file all match (i.e. "CustomExtension.dll" should have the assembly name "CustomExtension" and must be contained in the zip file "CustomExtension.bmx")

Tod, XML Configuration, in fact, is as you suggested, I was only using "MyAssembly" for reference. This is how I have it. <{Company}.ProGetExtensions.FilteredPackageStore Assembly="{Company}ProGetExtensions"> </{Company}.ProGetExtensions.FilteredPackageStore> I tried to start it from command line, same error.

Something like this should work: sealed class FilteredPackageStore : DirectoryPackageStore { private const int PackagesCount = 5; public override Stream Create(string packageId, SemanticVersion packageVersion, bool allowOverwrite) { var packagesToDelete = StoredProcs.Packages_GetPackages(this.FeedId, "Y") .Execute() .Where(p => p.Package_Id.Equals(packageId, StringComparison.OrdinalIgnoreCase)) .OrderByDescending(p => p.Published_Date) .Skip(PackagesCount); foreach (var package in packagesToDelete) this.Delete(package.Package_Id, new SemanticVersion(package.Version_Text)); return base.Create(packageId, packageVersion, allowOverwrite); } }

I see; in this case, your old extension is still being loaded. Maybe the service/webapp wasn't restarted, etc? Easy thing to test, add a new LogDebug(...) before that SPROC call.

Alana, thanks for the suggestion. I will look at adding this, but do you have any ideas how I can get the execution id for the current execution? There don't seem to be any variables for it. I thought of trying to get it from the BuildMaster API using an HTTP GET request, but I don't see a way to store that to a variable.

Hi Andrew, The ProcessRemoteCommand method only works when working with .NET-based agents. Behind the scenes, that method will serialize the action and use a sort of remoting to run that method on the remote server. With an SSH-based agent, this is obviously not possible. The CommandLineActionBase abstracts a lot of the complexity in executing remote processes. Just ignore the ProcessRemoteCommand method (throw a NotImplementedException) and try run the ExecuteCommandLine method from Execute. FYI - this is all being refactored in 4.0, and we're trying to phase out as many ProcessRemoteCommand-based actions as possible.

Code sent! hope this helps. A general rule of thumb... An action that inherits from ProviderBasedAction<T> is designed to run an operation on a single provider (Issue, Source Control, Database, etc). The provider and action plumbing take care of the agent and cross-platform things. If the provider doesn't already do what you want it to, then it's almost always easier to just run a command-line action (CommandLineActionBase), as that takes care of all the process logging and other things.