This project is read-only.

Visual Studio Community 2013

Nov 15, 2014 at 12:30 PM
Just thought I'd share this with you guys, because it's pretty frickin awesome. You can now download a copy of VS2013 Community edition. It has all of the same features that you find in the Professional edition, but it is completely free for non-enterprise application development.

http://www.visualstudio.com/en-us/downloads/download-visual-studio-vs#d-community

Perhaps this is also a good time to look at the future of .NET, and what it means for this project. Version .NET 4 is starting to show its age, but it is still widely used and officially supported by Microsoft until some time in 2016. What is our deprecation plan for .NET 4? Will we ever use .NET 4.5 as our baseline, or skip straight ahead to .NET 5 when that becomes available?

Related articles
Nov 15, 2014 at 10:27 PM
I was really excited to see .NET become open source, this means it'll get more widely adopted with time. Since I already have an ultimate version of VS2013 from my uni I don't need the community edition, still it is a great move by MS.

As for .NET4 and following: I was always in favour of .NET 4.5 since it gives us some great tools (async/await for example), therefore I propose we switch to 4.5 after we have reached our next milestone, that being implementing IREpository for every API endpoint.
Nov 15, 2014 at 10:39 PM
Edited Nov 15, 2014 at 10:41 PM
Oh, did I forgot to mention that I finished migrating /v1 to repositories? Sorry. Anyway, there's still work to be done before we can do another release. Right now, I'm thinking about how to design for /v2/recipes/search.

https://gw2dotnet.codeplex.com/workitem/1265
Nov 16, 2014 at 12:09 AM
.NET 4.5 only runs on Windows 7 and above. Is Windows XP/Vista support still relevant these days? I'd say it's irrelevant. Any machine that shipped with XP/Vista is probably too old to run modern games like GW2 anyway.
Nov 16, 2014 at 11:18 AM
Many users who don't like Win 7 or above have modern machines and install XP anyway. Still Win 7 has over 40% usage according to this website (german). And that is why I say we make the next milestone(repositories) happen with 4.0 and this will be the last official release for 4.0 after that you have to live with it and every new feature gets released for 4.5 and above.
Nov 16, 2014 at 11:34 AM
Would you say that our main focus is desktop, mobile or web development? I'm kind of undecided. Some things to consider:
  • The game itself only runs on desktops
  • Most fan-made content is web-based
  • Companion apps make more sense on separate mobile devices, than running them as desktop apps on the same machine
  • Overlay apps are awesome though
Right now, we touch on all areas, which is good. I haven't tested it, but I think we even run on Android and iOS using Xamarin. It's just that someone with a lot of time might make a library that targets only a specific platform, and is able to provide more and better features than we are able to support across all platforms.
Nov 16, 2014 at 5:22 PM
Edited Nov 16, 2014 at 5:22 PM
I just came across a very convincing argument to switch to .NET 4.5 as soon as possible. We can use MEF in a .NET 4 environment or .NET 4.5 environment, but we cannot use MEF in a mixed environment. So we have to give up either .NET 4 or WinRT support if we ever want to use MEF. Dropping .NET 4 instead of WinRT is pretty much a no-brainer.
Nov 17, 2014 at 9:32 AM
I'm pretty excited for .NET Core. I wish it was available right now. Mostly because they accept contributions from accepted contributors. Get your ass on that list by the way. All it takes is a single approved pull request, and it's a pretty good career move. They do set the bar high for code contributions, so don't half-ass it.
Nov 17, 2014 at 6:19 PM
Edited Nov 17, 2014 at 6:20 PM
Get your ass on that list by the way.
I'm looking at the standards, I wish I'd be this good right now. But .NET core is not over soon ;)
I just came across a very convincing argument to switch to .NET 4.5 as soon as possible.
That's why I'd say we make our next milestone and then switch to 4.5
Would you say that our main focus is desktop, mobile or web development? I'm kind of undecided.
Web and Desktop, both are equally important nowadays. The days of pure Desktop are over, internet is a major player, but full web content is also in the decline (thank god! that was an awful time). So we should use both equally.
Nov 17, 2014 at 7:16 PM
I think we should do a release. I've added MumbleLink support, added /v2/worlds support, added /v2/recipes support, changed every /v1 endpoint to a repository and also replaced the ServiceManager with a static GW2 class. I'm not forgetting anything, am I?
Nov 17, 2014 at 8:56 PM
I'm still not sure about the static GW2 class. I personally am not a fan of singletons, whethere they contain logic or not. I'll look at it tomorrow evening and decide whethere we do a release or not.

If we do, I want to make one more step before switching to 4.5: Converting the /v2/ namespace to repositories and clean up the namespaces a bit (will add work items on that), since I saw how or many, many namespaces interfere with a good documentation.
Nov 17, 2014 at 9:43 PM
Edited Nov 17, 2014 at 10:01 PM
The static GW2 entry point is a bit of a trade-off between proper design and user friendliness. I cannot expect a user to know how to construct repository objects. That's just too complicated. I may very well be the only person who knows how to do that.

Easy mode:
IRepository<int, Item> repository = GW2.V2.Items.ForDefaultCulture();
Pro's only:
Uri baseUri = new Uri("https://api.guildwars2.com", UriKind.Absolute);
ISerializerFactory jsonSerializerFactory = new JsonSerializerFactory();
IConverter<Stream, Stream> gzipInflator = new GzipInflator();
IServiceClient serviceClient = new ServiceClient(baseUri, jsonSerializerFactory, jsonSerializerFactory, gzipInflator);

IRepository<int, Item> repository = new ItemRepository(serviceClient);
The proper solution would be to use an IoC container instead of a singleton, but the base class library does not have any IoC containers built in to it. I also do not want to fall back to a third-party solution like Ninject/Autofac/Unity, but you're welcome to try and convince me otherwise.

__

I expect the namespace jungle to smooth out once we figure out how to use MEF to move /v1 and /v2 code into separate DLLs, so that all that remains in the Core library is core functionality.

Image

I think that MEF can also solve the problem of who's responsible for creating repository objects, even though it's not really an IoC container.

Not sure what you mean by converting /v2 to repositories? All endpoints already have a repository class.
Nov 18, 2014 at 9:34 AM
The proper solution would be to use an IoC container instead of a singleton, but the base class library does not have any IoC containers built in to it.
MEF has an IoC container built into it. That would mean, we can remove it after we are moving to MEF. However, isn't it possible just to leave the class as it is, but make it not static, what would be the tradeoffs in your opinion?
I expect the namespace jungle to smooth out once we figure out how to use MEF
I don't think it'll get better, we still have the namespaces and the documentation will reflect that. What I was thinking, on the example of the skins namespace, that we could just move everything from the skins.subnamespaces into the top namespace, so we wouldn't have Skins.Armors, Skins.Backbacks, Skins.Weapons, but just Skins.
Not sure what you mean by converting /v2 to repositories?
So each endpoints already implements IRepository? Good, I'll look over the code today evening.
Nov 18, 2014 at 10:23 AM
MEF has an IoC container built into it. That would mean, we can remove it after we are moving to MEF. However, isn't it possible just to leave the class as it is, but make it not static, what would be the tradeoffs in your opinion?
 
Having to (remember to) write new GW2() instead of GW2.
What I was thinking, on the example of the skins namespace, that we could just move everything from the skins.subnamespaces into the top namespace, so we wouldn't have Skins.Armors, Skins.Backbacks, Skins.Weapons, but just Skins.
 
I agree, we should get rid of subnamespaces.
So each endpoints already implements IRepository? Good, I'll look over the code today evening.
 
Don't just look at the code. Try running it.
Nov 18, 2014 at 12:38 PM
MEF has an IoC container built into it.
 
I thought this was false, but it seems to be true for MEF 2 (.NET 4.5 only). For classic MEF, you only get a composition container. The difference? Composition requires that you decorate the code with [Import] and [Export] attributes. An IoC container does not require any modifications to the code.
Nov 18, 2014 at 6:35 PM
Edited Nov 18, 2014 at 6:43 PM
I cleared out the sub-namespaces. There are currently 935 different types in the Core assembly, scattered across these namespaces.
 
  • GW2NET.Builds
  • GW2NET.ChatLinks
  • GW2NET.Colors
  • GW2NET.Common
  • GW2NET.Commerce
  • GW2NET.Common.Converters
  • GW2NET.Common.Drawing
  • GW2NET.Common.Serializers
  • GW2NET.DynamicEvents
  • GW2NET.Files
  • GW2NET.Guilds
  • GW2NET.Items
  • GW2NET.Local.DynamicEvents.Xml
  • GW2NET.Local.DynamicEvents
  • GW2NET.Maps
  • GW2NET.Quaggans
  • GW2NET.Recipes
  • GW2NET.Rendering
  • GW2NET.Skins
  • GW2NET.V1.Builds
  • GW2NET.V1.Colors
  • GW2NET.V1.Continents
  • GW2NET.V1.DynamicEvents
  • GW2NET.V1.Files
  • GW2NET.V1.Floors
  • GW2NET.V1.Guilds
  • GW2NET.V1.Items
  • GW2NET.V1.Maps
  • GW2NET.V1.Recipes
  • GW2NET.V1.Skins
  • GW2NET.V1.Worlds
  • GW2NET.Worlds
  • GW2NET.V1.WorldVersusWorld.Matches
  • GW2NET.WorldVersusWorld
  • GW2NET.V1.WorldVersusWorld.Objectives
  • GW2NET.V2.Commerce.Exchange
  • GW2NET.V2.Common
  • GW2NET.V2.Commerce.Listings
  • GW2NET.V2.Commerce.Prices
  • GW2NET.V2.Items
  • GW2NET.V2.Quaggans
  • GW2NET.V2.Recipes
  • GW2NET.V2.Worlds
The way I'm seeing it, MEF will help us shrink it considerably...
 
  • GW2NET.Builds
  • GW2NET.ChatLinks
  • GW2NET.Colors
  • GW2NET.Common
  • GW2NET.Commerce
  • GW2NET.Common.Converters
  • GW2NET.Common.Drawing
  • GW2NET.Common.Serializers
  • GW2NET.DynamicEvents
  • GW2NET.Files
  • GW2NET.Guilds
  • GW2NET.Items
  • GW2NET.Maps
  • GW2NET.Quaggans
  • GW2NET.Recipes
  • GW2NET.Rendering
  • GW2NET.Skins
  • GW2NET.Worlds
  • GW2NET.WorldVersusWorld
So what about the other namespaces?

Every V1 and V2 namespace gets a separate DLL and separate documentation.
 
  • GW2NET.V1.Builds.dll
  • GW2NET.V1.Colors.dll
  • GW2NET.V1.Continents.dll
  • GW2NET.V1.DynamicEvents.dll
  • GW2NET.V1.Files.dll
  • GW2NET.V1.Floors.dll
  • GW2NET.V1.Guilds.dll
  • GW2NET.V1.Items.dll
  • GW2NET.V1.Maps.dll
  • GW2NET.V1.Recipes.dll
  • GW2NET.V1.Skins.dll
  • GW2NET.V1.Worlds.dll
  • GW2NET.V1.WorldVersusWorld.Matches.dll
  • GW2NET.V1.WorldVersusWorld.Objectives.dll
  • GW2NET.V2.Commerce.Exchange.dll
  • GW2NET.V2.Common.dll
  • GW2NET.V2.Commerce.Listings.dll
  • GW2NET.V2.Commerce.Prices.dll
  • GW2NET.V2.Items.dll
  • GW2NET.V2.Quaggans.dll
  • GW2NET.V2.Recipes.dll
  • GW2NET.V2.Worlds.dll
These DLLs would then be loaded into a CompositionContainer. The container itself then creates instances of repositories using the implementations from the given DLL.
Nov 19, 2014 at 3:21 PM
I created hidden entries for the next two releases.
Each page is only visible to project members right now, so feel free to edit. When the release looks good enough, make it public.
Remember that 0.9.12 is already a huge improvement over 0.9.11, so don't spend too much energy on the details.
Nov 25, 2014 at 11:41 AM
I'll not be able to do much in the ext few days, but a release should be possible. For the version after the next one, you can create a "planned" release, where our users can get a preview of what to expect.