{"action":"created","issue":{"url":"https://api.github.com/repos/ewoutkramer/fhir-net-api/issues/178","repository_url":"https://api.github.com/repos/ewoutkramer/fhir-net-api","labels_url":"https://api.github.com/repos/ewoutkramer/fhir-net-api/issues/178/labels{/name}","comments_url":"https://api.github.com/repos/ewoutkramer/fhir-net-api/issues/178/comments","events_url":"https://api.github.com/repos/ewoutkramer/fhir-net-api/issues/178/events","html_url":"https://github.com/ewoutkramer/fhir-net-api/issues/178","id":139269486,"number":178,"title":"Support for dnxcore50?","user":{"login":"IDispose","id":379719,"avatar_url":"https://avatars.githubusercontent.com/u/379719?v=3","gravatar_id":"","url":"https://api.github.com/users/IDispose","html_url":"https://github.com/IDispose","followers_url":"https://api.github.com/users/IDispose/followers","following_url":"https://api.github.com/users/IDispose/following{/other_user}","gists_url":"https://api.github.com/users/IDispose/gists{/gist_id}","starred_url":"https://api.github.com/users/IDispose/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/IDispose/subscriptions","organizations_url":"https://api.github.com/users/IDispose/orgs","repos_url":"https://api.github.com/users/IDispose/repos","events_url":"https://api.github.com/users/IDispose/events{/privacy}","received_events_url":"https://api.github.com/users/IDispose/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":17,"created_at":"2016-03-08T12:46:32Z","updated_at":"2016-07-05T13:42:36Z","closed_at":null,"body":"Any plans to support dnxcore50? "},"comment":{"url":"https://api.github.com/repos/ewoutkramer/fhir-net-api/issues/comments/230481565","html_url":"https://github.com/ewoutkramer/fhir-net-api/issues/178#issuecomment-230481565","issue_url":"https://api.github.com/repos/ewoutkramer/fhir-net-api/issues/178","id":230481565,"user":{"login":"wpostma","id":1833470,"avatar_url":"https://avatars.githubusercontent.com/u/1833470?v=3","gravatar_id":"","url":"https://api.github.com/users/wpostma","html_url":"https://github.com/wpostma","followers_url":"https://api.github.com/users/wpostma/followers","following_url":"https://api.github.com/users/wpostma/following{/other_user}","gists_url":"https://api.github.com/users/wpostma/gists{/gist_id}","starred_url":"https://api.github.com/users/wpostma/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wpostma/subscriptions","organizations_url":"https://api.github.com/users/wpostma/orgs","repos_url":"https://api.github.com/users/wpostma/repos","events_url":"https://api.github.com/users/wpostma/events{/privacy}","received_events_url":"https://api.github.com/users/wpostma/received_events","type":"User","site_admin":false},"created_at":"2016-07-05T13:42:36Z","updated_at":"2016-07-05T13:42:36Z","body":"Okay. So my initial incompetent puttering has resulted in the following interesting (if a bit predictable to a more experienced .net guru than me) factoids:\r\n\r\n1. Placing a project.json file into a directory containing WORKING .net full framework C# project (.csproj) is sufficient to break the visual studio IDE's ability to open and build the previously working project.  Having a .net core .xproj and project.json in the same root directory as a classic C# project .csproj appears not to be supported or possible in visual studio 2015 update 3.  I have also found some code that won't compile in the .net core compiler which is odd.    Ability to actually build a fully native set of packages for .net core is thus made significantly more difficult.  That means that using a PCL fhir-net-api package set is the ONLY option.   My initial knee-jerk idea of \"Let's make a completely .net core native package set\" would require either me maintaining a separate fork on github, or some kind of build-time trickery where the .net core project files are kept away from the main sources, placed in place and then used for a dotnet build from a command line, then whisked away again afterwards.\r\n\r\n2. When you create a Portable Class Library project, what you are creating is a project which can be compiled inside the visual studio IDE or from the command line, via msbuild, but this project does not contain a project.json, but presumably such PCLs, marked with the correct \"profile\" should be workable on all selected platforms. \r\n\r\n3. Since fhir-net-api depends on T4 macros (.tt) I am attempting to discover also if horror stories I have previously read about trying to run T4 macros in  continuous integration which may work differently when run inside the IDE because two different T4 engines are used when you run T4 code generation tasks inside the full IDE and from MSBUILD. (MSDN ref: https://msdn.microsoft.com/en-us/library/ee847423.aspx ) -- Is this project currently free of such T4 glitches or is there anything I need to be aware of? Such things would be great to be in the project readme.\r\n\r\n4. I may have found a compiler bug which fails to generate an \"== null\" operator overload for an optional enum (Enum?) types.  http://stackoverflow.com/questions/38191166/c-sharp-optional-enum-type-property-setter-compiles-in-classic-net-but-not-in\r\n\r\n"}}
{"actor":{"display_login":"wpostma"}}