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.

We don't have one.... for now we're planning on featuring our deploy features in v3. Any suggestions or things you think we should do?

I believe this is a bug in NuGet; https://nuget.codeplex.com/workitem/4050 If not, I would suggest to do a fiddler trace to see specifically which url is failing,.

We had considered this feature when designing ProGet, but ultimately didn't implement it. One very popular workflow is to have BuildMaster push the packages to different feeds based on environment. Have you considered using that?

Yes Spaces were in all of my feed names. Removing the spaces resolved my issue. Removing the spaces also resolved the issue where the Download button was not working which I had reported in another thread. Thanks.

I get the same error with nuget.exe 2.7,2.6 and 2.5. We hope you can fix it in future version

There is no current way (as of 3.0.0 beta) to do this built-in, but could be done with an extension. A feed adapter is probably the best way to handle this. I'm not sure what you mean by the 2nd half of your question... you don't have to pull the package to download it from a connected feed - there is a download button just the same as if it was in your private feed.

The exact process is detailed on the page used to switch over, but here are some troubleshooting ideas: ensure both Windows Auth & Forms Auth enabled for the website ensure Anonymous Authentication is disabled ensure there are administrator privileges granted before switching perform an iisreset on the web server if using IIS

Yes, and we have actually already implemented it for our next release :) We're thinking of releasing a beta version of 3.0 today if you want to be on the lookout for it.

Thanks for the report! Just update the site to fix this.

I must be missing something here, but if you remove the View Only privilege to download packages, you should be forbidden from downloading packages... Are you saying you removed your View Only privileges, or that you removed them from the Anonymous User such that it has no privileges? If it's the latter, can you send a Fiddler trace containing the requests that Visual Studio extension is attempting to send?

Yes, all good. That directory is monitored for changes, and when a change occurs, the contents are re-indexed.

I just restarted the service and now it's showing the new version...