NuGet Package

Sep 11, 2014 at 5:09 PM
Hey guys, first of all just want to say this library has some quality work in it. Thanks for putting in the time to create a clean, up-to-date library for the GW2 Api! I've recently switched to using Guild Wars 2 .Net as my primary API library for the GW2 PAO.

I wanted to ask what the status was of the NuGet Package. I tried messaging Ruhrpottpatriot, but I'm not sure it went through. It appears that the package is a bit out-of-date. Are there plans to keep the NuGet package up-to-date, or should I just keep checking back here for the latest version?

Sep 11, 2014 at 6:17 PM
Thanks for the compliment!

We don't really have a workflow for managing releases. I don't even have permission to update the NuGet package. It always takes time for the NuGet package to catch up with the latest release, but we're now looking into solving that problem. Ideas are welcome.
Sep 12, 2014 at 10:50 AM
By the way, feel free to join the team. It's the best way to ensure that fixes are implemented quickly. There are a number of places where the code always breaks whenever the API is changed. For example: new item.type or item.flag constant values always cause the code to crash for those item identifiers, because the code does not know about those constants. This only occurs when the game is updated, but still. Adding the new constants will always require manual intervention.
Sep 13, 2014 at 12:19 AM
I actually have never created a NuGet package myself, so I'm not sure of the general process involved in doing so.

Thanks for the invitation to join the team! I'd love to contribute if I notice any bugs/issues, however there doesn't seem to be a way to request to join the team. It looks like I have to be invited?
Sep 20, 2014 at 10:37 AM
A little head up: I wanted to update the NuGet Package some time ago, but University studies came in between and then I had to do my officers training for two weeks and I had no internet. Packages will be updated today. I promise
Sep 20, 2014 at 3:03 PM
I quickly published the packages. I already did them but apparently forgot to push them to NuGet.

However I'll look into separating the assemblies into separate packages.

Steven, you put the GW2.NET R# files in the main package, is that supposed to be that way? Shouldn't they be in a separate package?
Sep 20, 2014 at 3:30 PM
Edited Sep 20, 2014 at 3:32 PM
I messed up before. The RestSharp assemblies should not be a part of the package. I added nuspec files to source control that creates v0.9.9 packages in the correct format.

Can you use that to replace the current 0.9.9 package?

Or just use these:
Sep 20, 2014 at 4:43 PM
Edited Sep 20, 2014 at 4:44 PM
Replacing packages is not possible in NuGet. I'd have to upload a new version, but I went through the nuspec file (which I do not have somehow) and my package is according to that files.

And what about the R# fine in the contracts folder. I guess it too should not be part of the package?
Sep 20, 2014 at 4:51 PM
Edited Sep 20, 2014 at 5:09 PM
More links:

These should be in your workspace folder after performing a 'Get latest'. These configurations create packages with all the right files in all the right places.

It's a little annoying that the package can't be replaced, but it's important that you upload a package with the correct configuration. Otherwise, people will get very confused when they install a package that doesn't work.

GW2.NET. :
GW2.NET.RSharp. :

These are tested and known to work.

The most important part of the configuration file is the <references> tag that indicates which files should be added as a reference.
Sep 21, 2014 at 3:55 AM
This is great. Thanks guys! I'll definitely be making use of this asap.
Sep 22, 2014 at 9:26 AM
I want to add that is not yet on NuGet, since it is identical to Since the step towards mobile support I always wanted to separate the package into smaller ones (like we did with the R# stuff). Now seems like a good time for that.
Sep 22, 2014 at 9:47 AM
Edited Sep 22, 2014 at 9:48 AM
It's not identical! The <references> tag is incorrect in the current live package. That means that you have to manually fix the references after installing, which is extremely confusing.

The problem is that NuGet automatically references the code contracts libraries. This is just plain wrong, and causes compilation errors about class name collisions. The only fix is to manually specify which DLLs should be referenced.
   <reference file="GW2.NET.dll" />
   <reference file="GW2.NET.Core.dll" />
Sep 22, 2014 at 1:23 PM
Will change it asap, when I get home from uni.
Sep 22, 2014 at 8:58 PM
Changed it. Now everything should be fine.
Jun 9, 2015 at 11:29 PM
Hey guys, just dropping a post here as a request for the GW2NET.V2.Items Nuget Package to be updated with the latest fix for Issue 1349. I'm pretty sure everything is good to go, it just has to actually be deployed, which I'm assuming only Ruhrpottpatriot can do... Thanks!
Jun 10, 2015 at 7:52 AM
As a temporary workaround, you can create a nuget feed from a local directory. Creating the package is just a matter of running nuget.exe pack on the right project file after building.
Jun 13, 2015 at 11:44 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jun 23, 2015 at 3:28 PM
Package will be updated later this day. I'm getting my workspace ready after setting up my pc again.
I'm pretty sure everything is good to go, it just has to actually be deployed, which I'm assuming only Ruhrpottpatriot can do... Thanks!
Yes only I can deploy packages right now. I know I have been slow in this regard, but it has something to do with university. I switched from Law to Computer Science and thus have to repeat a whole bunch of mathematics I needn't use for five years.

Up until we get the whole continuous integration done I want to control the pace of the releases. It is not that I don't trust you, but since I am the coordinator for this project I want to be sure the way we are heading.
Codeplex hasn't written back for a conversion from TFS to Git, so I'll be pinging them again today, in hopes we can migrate in the next weeks.
Jun 25, 2015 at 1:55 PM
Edited Jun 25, 2015 at 1:57 PM
Sweet! Thanks.

Ruhrpottpatriot wrote:
Up until we get the whole continuous integration done I want to control the pace of the releases.
It's not something that gets done. It's continuous!

More precisely, it means that every changeset will be automatically compiled + versioned + pushed to a custom nuget feed (MyGet or self-hosted).

As before, is used for milestone releases. Pushing new packages to still has to be a conscious decision that is not to be taken lightly.

The intended result is that you can easily switch between stable builds ( and the latest development builds ( using the NuGet package manager in Visual Studio.
Jun 30, 2015 at 8:00 PM
It's not something that gets done. It's continuous!
That's not what I meant. I meant the whole process of moving from our current setup to continuous integration.