Are you overwriting an existing package when this happens, or are these fresh packages that are getting uploaded? Either way, if you could send that Process Monitor output to support@inedo and reference this post that would be very helpful, thank you!

At this point in time, it is unlikely. However, Atlassian does mention on their site that plugins could be created to integrate with third-party tools, and the JSON ProGet API could be used for this.

Not as of 3.8, but there will be a UI refresh in v4.0 (due later this month) and that will no longer be in the navigation bar.

Tod, I justed tested it and it works perfectly. You can see this API being used in Fiddler when you use the "Show all versions" link for a package in NPE. Previously doing that didn't work against a ProGet feed. Thank you for the fast turn-around! That was impressive... Riko

Thanks Philipp, we've identified some additional performance issues as well and will plan to release a maintence ProGet release to fix this .. ideally today.

Unfortunately, the "Download Dependencies" feature can act a little funny because the way NuGet does dependencies is a little funny. It's on our list to improve this functionality.

Yes, just edit the connection string in both the web and services directory.

Are you using the integrated web server, or hosting via IIS? Regardless, if you don't want to just delete the ProGet database and start from scratch, you can run the following command from PowerShell or a CMD window to reset the authentication mechanism: sqlcmd -E -S localhost -d ProGet -Q "UPDATE Configuration SET Value_Text = 'false' WHERE Key_Name = 'LDAPEnabled'" You can additionally reset the Admin user by running the ProGet.Service.exe executable and selecting Action 7 "ResetAdminPassword".

To back-up ProGet, you just need to Back-up the Database and the Packages directory (the path is listed on each feed, and is in the All Settings under Admin).

Hi, Thanks for the bug report; this will be addressed in the next release of ProGet, which is due in just a few days!

The service does need to be running mainly to index packages. If you selected the IIS option during install, the web server in the service will not run. If you are switching from integrated web server to IIS, make sure to update the service's .exe arguments to exclude the /urls argument and then the web server component of the service will not run.

For completeness, v3.0.3 was just published which adds an index to Publish_Date and the dashboard query now returns virtually instantly tested against 100,000+ packages in the database.

I didn't run it as an admin, but I think it popped up the UAC prompt. Also, it managed to delete most of the contents of the proget directory in program files. Unfortunately, that's all the info I've got. Hope it helps you out.

Unfortunately at this point, we have no good examples of this sort of thing. You might be able to get away with inheriting from DirectoryPackageStore and extending its behavior on EnableChangeNotifications() to add your own FileSystemWatcher, but it all seems unnecessarily complicated when a simple scheduled task would do the trick.

Hi, I was having same issue and finally I managed to get mine working. One thing that helps you identify the issue is this using the Module window in VS: Create a console app and install package Add a break point and Run it in VS Open Module window (Main Menu > Debug > Windows > Module) Find your module and check whether the symbols are loaded (in the status) Right-click on the module and click on Symbols Load Information... Thats the main diagnostics that got mine working, what I also had wrong most likely (not too sure about them tho). I was packing this way: Perform an MSbuild on .sln Invoke nuget pack on .csproj e.g. :> pack proj.csproj -sym Instead I'm doing this now: Make sure the bin (output folder) is cleaned. Invoke nuget pack on .csproj with build. e.g. :> pack proj.csproj -sym -build -Prop Configuration=Release Hope it helps.

Thank-you for the quick reply... I had just upgraded Proget just a week ago or something, so I hadn't thought to look for another version. I downloaded and installed the latest version and indeed my issue seems to be resolved.

Thanks Tod! Works like a charm. Perhaps a better approach would be to clear the handlers and add only the ones used by the application? In any case that pretty much solves it for us (until the next problematic suffix...) Thank you.

we fixed our problem. after many tests we found out that we must use the absolute name of the package "CompanyName.Project.Common.Application" and not only application.

This is not a very common scenario, so I would suggest altering your workflow to not always update the packages if they don't change. Alternatively you'll need to add some custom steps such as deleting the package before pushing it, or using a custom package store.

It looks like that particular package has a .nuspec file that does not match the name of the package ID. If you change the name of the nuspec file inside the package to match the package ID it should be able to be indexed. We will add a better error message for this in the next version.