TransformJsx task failing unexpectedly.

[madmikeross]

Hi all,

I'm getting a handful of errors when attempting to build a Web API project (ASP.NET 4).

I am using the default TransformJsx.proj:

I have attempted adding a TargetDir property as seen here(http://reactjs.net/guides/msbuild.html) but had no luck.

Any help would be greatly appreciated.

[Daniel15]

I recently saw the same thing on my own site after upgrading Newtonsoft.Json (JSON.NET) past version 5.0.4. Downgrading to JSON.NET version 5.0.4 made it work as expected so there's probably some incompatibility somewhere. I'll take a look.

[madmikeross]

Hey Daniel, thanks for the suggestion. Unfortunately, JSON.NET 5.0.4 is incompatible with Microsoft.Owin.Security (version 3.0.0) and others.

I also tried upgrading from JSON.NET 6.0.4 to 6.0.8 because it looked like there were some 'unsupported type' fixes. No luck there either. If it weren't for the security requirements of this project, I would just downgrade to 5.0.4.

Thanks for your attention on the issue, I will check back.

[Daniel15]

I'll try to take a look this weekend and see if I can figure out what's up :)

[Daniel15]

That was pretty tricky to track down, but it did end up being an issue with the JSON.NET version:

The "real" error message was masked by that try-catch block in that segment of code. The try block had logic for parsing the data as JSON, but the catch block did not. This meant that the error that ended up being thrown was due to the code paths being different, which is why I was confused by it.

This actually seems somewhat specific to the MSBuild task which is probably why I haven't gotten other reports about it (not many people use the MSBuild task). NuGet automatically inserts assembly bindings into the Web.config which means assembly version issues don't really happen with sites (or desktop apps) as long as the API remains backwards-compatible between versions. MSBuild can't really use assembly bindings.

Anyways, 5021d39 fixed the code so the two code paths do the same thing (which made it start throwing the correct error about Newtonsoft.Json) and 292cf49 updated the referenced version of Newtonsoft.Json. The new build will be on the development package server shortly (instructions here), or you can build it yourself if you like.

[madmikeross]

Awesome Daniel, thanks for the support. I will give it a whirl in the
morning.
On Mar 15, 2015 7:28 PM, "Daniel Lo Nigro" [email protected] wrote:

That was pretty tricky to track down, but it did end up being an issue
with the JSON.NET version:

[image: Error message]
https://cloud.githubusercontent.com/assets/91933/6659698/511cc3d4-cb48-11e4-8d47-a3dc3c680a4a.PNG

The "real" error message was masked by that try-catch block in that
segment of code. The try block had logic for parsing the data as JSON,
but the catch block did not. This meant that the error that ended up
being thrown was due to the code paths being different, which is why I was
confused by it.

This actually seems somewhat specific to the MSBuild task which is
probably why I haven't gotten other reports about it (not many people use
the MSBuild task). NuGet automatically inserts assembly bindings into the
Web.config which means assembly version issues don't really happen with
sites (or desktop apps). MSBuild can't really use assembly bindings.

Anyways, 5021d39
5021d39
fixed the code so the two code paths do the same thing (which made it start
throwing the correct error about Newtonsoft.Json) and 292cf49
292cf49
updated the referenced version of Newtonsoft.Json. The new build will be on
the development package server shortly (instructions here
http://reactjs.net/getting-started/download.html#development-builds),
or you can build it yourself if you like.

—
Reply to this email directly or view it on GitHub
#104 (comment).

[madmikeross]

I gave the development package a whirl but bumped into the same issue (the update might not have propagated yet?). I did build it and my issue has been resolved, thanks again.

[Daniel15]

Yeah it looks like the build on the dev server is broken even though I have
no issues compiling the project myself (even on a fresh checkout), not
quite sure what's going on there. Thanks for checking it :)

Regards,
Daniel Lo Nigro
http://dan.cx/ | Twitter http://twitter.com/Daniel15 | Facebook
http://www.facebook.com/daaniel

On Mon, Mar 16, 2015 at 8:31 AM, Michael Ross [email protected]
wrote:

I gave the development package a whirl but bumped into the same issue (the
update might not have propagated yet?). I did build it and my issue has
been resolved, thanks again.

Reply to this email directly or view it on GitHub
#104 (comment).