If the installer is signed by Inedo, then you can be assured it's a false positive. We have no control over how A/V companies detect "viruses", but if you could please report this as a false positive, then they will be less likely to falsely detect our installers.

It's not that "tags appear to become meaningless once a newer version of a package is present", it's just that tags are part of an individual package's metadata (see the NuSpec Reference) just like name, description, authors, etc. The VS Client, nuget.org, and every other package manager UI we've worked with will only do metadata search on the most current version of a package by default; otherwise, outdated and irrelevant packages would come up in results. As you can see, it's possible to use an API to search for these things... but tags are simply not intended to solve the problem I think you're trying to solve.

Here are the actions that aren't supported via SSH agent currently: Unit Test Actions HTTP Reporting Actions Generate Release Notes Action (unless running on BuildMaster server) Execute Database Change Scripts Action Rename Files Action (shell script is recommended for this) Set File Attributes Action (shell script is recommended for this)

You can just edit the workflow step and select the deployment plan you want for that particular workflow step. There was a bug fixed in the v4.7.4 version that caused this behavior, typically when combined with Build Steps and multiple workflows. If you upgrade to the latest maintenance release for your minor version (i.e. v4.7.5) the copy should work as designed in all cases.

The page was changed in v4.8.2 to only show the first 30 releases for perf reasons, so if you have more active releases than that, the list would be truncated to the first 30 ordered by when they were created. We're open to making this behavior configurable instead of a strict limit of 30.

I see, that's perhaps the most common usecase for ProGet, so it should just work. I suggest to attach Fiddler, or Wireshark, then compare the results between one computer and the next. Then you can see exactly what the results are. Something could be filtering it in between, redirecting to the wrong server with a hosts file, etc.

The Build MSBuild Project actions effectively just run msbuild.exe against your project files; so, I would start there. KB1052 offers some troubleshooting tips, see the "Issues with third-party tools and integrations" section for how to dig into the details.

Nice. It would be even better if you could see this log info next to "Last updated" while browsing a package.

I'm afraid I don't have enough information to help diagnose this problem. Please keep in mind, BuildMaster isn't actually looking for anything -- it's essentially just executing a third-party tool like nuget.exe and msbuild.exe with the arguments you specify, so it's important to look at both the arguments to those commands and the working directories those commands are being run in. These will be logged near the top log for the action.

The issue turned out to be more of a Nuget issue, I believe. According to Nuget's docs, I should be able to mirror my package by specifying the push package URL in the following format: (proget server)/api/v2/package/. However, this just grabs the first feed under /package. Instead I needed to specify the feed name: (proget server)/api/v2/package/myfeed

Is there any other error information e.g. stack trace or error details? You can look in the Windows Event Log for more info.

the error was not occuring when trying to select project. Browsing worked perfectly, i was able to browse and choose my SLN file. the error occurred upon clicking "next". All that aside, installing .NET 4.5 seems to have resolved the issue. 4.5 is not a requirement for vault or for BuildMaster, but seems to have changed something. I found an unrelated artical on google saying that they were getting a MaxArrayLength error, and that the error went away after installing .NET 4.5, so i figured it was worth a shot, and sure enough issue resolved!

Sure, happy to share the source, though you're welcome to use a disassembler or reflection tool as well -- easiest thing would to fill out the Source Code Request and we'll email it on over. If you only ever had a single, well-known database to work with, then hard-coding the connection string isn't too bad of an idea. You can always just update the code and redeploy the extension if it ever changes. But since you have multiple databases... I'm not sure if it's the best approach. Otherwise, consider that any property on your class that you mark with the Persistent will be displayed as a textbox and it will be available at runtime. So, two ideas come to mind: You could have a ConnectionSTring property, and just use that; that would be quite easy You could have DatabaseConnectionName property, and have that reference a database connection within your application; these are used to deploy database changes The DatabaseConnectionName will be a little trickier, as you'll have to retrieve it from the database, then deserialize it, then look at the object's connection string property. All of the Database ACtions do this, so you can look at their source code. You'd only want to do this if you're already using database connections.

It's hard to say why there's a discrepancy, but you can just re-index the entire connector. Just run the "FullNpmConnectorIndex " scheduled task, accessible from the admin portal. This will take several minutes. There will be a LOT of warnings about "missing versions property". You can ignore thesethey are effectively invalid npm packages that they return anyway with the index request.

Hi Damian, I completely that you shouldn't have to install a client to use TFS. Unfortunately, only the most recently (v2015) libraries are licensed for redistribution, and these libraries require .NET 4.5, whereas BuildMaster v4 only requires .NET 4.0. These libraries also don't seem to connect to earlier versions of TFS unless VS2015 was actually installed; it's a bit frustrating for us, and other ISVs as you can imagine. We have requested a redistribution license of the earlier libraries, and we can continue to explore getting it to work on our end, but it's not at all trivial. The currently solution is to GAC the assemblies yourself or to install the TeamExplorer 2013 client, which does GAC these assemblies.

Thanks Tod. I have run the provided SQL and can confirm that the View Purge History page is now working again. Cheers.

Visual Studio is filtering out your package because your project is targeting a different framework than your package is configured for. For example, you may have a net45 package and are trying to make a net35 project

I assume you can see the package when you browse the feed in ProGet? If so, then Visual Studio is filtering out your package because it's targeting a different framework than your package is configured for. For example, you may have a net45 package and are trying to make a net35 project.

Just a quick note to add to this, there is a setting on the Admin->Advanced Settings page called AllowDropPathImportOverwrite that will allow drop path packages to overwrite feed packages when set to true.

Yes, there is, but I'm afraid we don't have a detailed set of instrucitons on how to do that. Effectively though, you need to install the certificate to the host name you wish to use, and then change the url to https. However, we strongly recommend using IIS hosting if you want to do this, as there are plenty of guides available on how to do this, and administrators will be much more familiar with how to manage certificates.