After having to clear 5 Gigs from my hard drive for MSVC 2015, I can't seem to find Empty Project{"name":"609972","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/0\/a0f5e9d723fbd0a0a8ed4f0cc2d85797.png","w":1100,"h":800,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/0\/a0f5e9d723fbd0a0a8ed4f0cc2d85797"}

How does one go about getting a package on NuGet? Is it a lot of work?

FYI, I've found NuGet to be more trouble than its worth in professional work. We use it to manage several packages from .NET libraries and frameworks to JavaScript libraries. It's generally quite a mess. And we haven't figured out the right incantation to mix it with version control... This is literally a Windows-style package manager... It lacks many of the things that make package repositories Just Work(tm). It's generally a poor way to pull in JavaScript library updates. For Allegro's purposes I think it will solve the problem quite nicely!

Is this a full static build of Allegro, or DLL? I'm currently including self-built static Allegro monoliths in the minisphere Git repo and it would be nice to be able to quit doing that.

It comes with a non-monolith release, non-monolith debug and a monolith static release (since there's no practical difference between monolith and non-monolith static builds) builds. The release builds statically link the runtime, but as per a request in a different thread there'll probably be a dynamically linked runtime static release build version at some point.

I think SL is being modest, as usual. He knocked all the rough edges off my package definition and made it usable.

Couple of points:

Unlike Linux where the packaging is fundamental to the concept of a 'Linux Distribution', Nuget feels a bit of an afterthought. I have a horrible feeling MS is not 100% behind it though it does seem to be gaining popularity at the moment.

It seems to handle different tool sets and platforms by just including all possible variants in the same package - one for each version of Visual Studio times each debug/release variant times each processor. This makes for big packages which AFAICS are copied in their entirety into each project that uses them.

Nuget only copies the files and makes sure the project settings reference them, so you shouldn't have to do anything different.

I would first check you aren't accidentally mixing in any other versions of Allegro that you have installed, and if that's not the problem, is it possible for you to zip up a minimal example project and post it here, or file an issue on https://github.com/SiegeLord/allegro_winpkg/issues ?

The "allegro-debug.pdb" symbol file is missing and/or not deployed with the NuGet package so when a program crashes it's impossible to trace them back to figure out what was passed to Allegro's functions to figure out what was wrong.

Hmm... we never actually distributed pdb files before. The debug versions are sort of more for triggering the asserts inside allegro, rather than necessarily backtracing into it. Currently our build system doesn't install them correctly (and it doesn't appear that it builds them correctly for the monolith library), but if we fix that, we could probably distribute them.

The reason I ask is because I'm currently having an issue of a crash-on-close where something has gone out of scope and/or cleaned up via RAII smart pointers and allegro tries to handle it after returning from main. All I get is "Could not find allegro-debug.pdb" from Visual Studio 2015 when stepping through. Digging through (at most) 30,000 lines of code to find where my program is passing an expired value is going to take forever.

Most of my experience in Windows/Visual Studio land is with .NET code so maybe it's different, but typically when you build a foo.dll using a Debug profile there is a foo.pdb created alongside it. I'm curious if this "allegro-debug.pdb" is a literal error message or is an approximation, and if it's exact then what symbols within the package match "allegro-debug"?

It's obvious that a heap-allocated variable has gone out of scope and cleaned itself up (I'm using C++11 smart pointers) and then Allegro tried to do some cleanup with it but without a Call Stack or symbols available I have no idea which variable went out of scope nor which function tried to access it.

EDIT

After deleting the output folders and rebuilding to make sure I have the correct DLLs loaded (I still had a few of the 5.0.10 DLLs in them, now they are all 5.1) I still get the same error.

Have you correctly implemented copy constructors for your 'smart' objects? You can easily add in a printf statement here and there to see what kind of object it is, or add in a divide by zero if you detect a double free to get a breakpoint.

If you're copying objects naively (shallow copy), that could easily be the source of a double free when the original is destroyed and then the copy goes out of scope it will free it again. That's my guess without looking at any code.