ReactJS.MSBuild cannot find Newtonsoft.Json Version=9.0.0.

[jadebayo]

Trying to add React.MSBuild, but when the TransfomrBabel Task is called i get this issue. My project uses Newtonsoft.Json 11.0 and there is a assembly redirect to it.

1> : error MSB4018: The "TransformBabel" task failed unexpectedly.
1> : error MSB4018: React.TinyIoC.TinyIoCResolutionException: Unable to resolve type: React.IReactSiteConfiguration ---> System.TypeInitializationException: The type initializer for 'React.ReactSiteConfiguration' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.
1> : error MSB4018: at React.ReactSiteConfiguration..ctor()
1> : error MSB4018: at React.ReactSiteConfiguration..cctor()
1> : error MSB4018: --- End of inner exception stack trace ---
1> : error MSB4018: at React.ReactSiteConfiguration.get_Configuration()
1> : error MSB4018: at React.AssemblyRegistration.<>c.b__2_0(TinyIoCContainer c, NamedParameterOverloads o)
1> : error MSB4018: at React.TinyIoC.TinyIoCContainer.<>c__DisplayClass29_0`1.b__0(TinyIoCContainer c, NamedParameterOverloads o)
1> : error MSB4018: at React.TinyIoC.TinyIoCContainer.DelegateFactory.GetObject(Type requestedType, TinyIoCContainer container, NamedParameterOverloads parameters, ResolveOptions options)
1> : error MSB4018: --- End of inner exception stack trace ---
1> : error MSB4018: at React.TinyIoC.TinyIoCContainer.DelegateFactory.GetObject(Type requestedType, TinyIoCContainer container, NamedParameterOverloads parameters, ResolveOptions options)
1> : error MSB4018: at React.TinyIoC.TinyIoCContainer.ResolveInternal(TypeRegistration registration, NamedParameterOverloads parameters, ResolveOptions options)
1> : error MSB4018: at React.TinyIoC.TinyIoCContainer.Resolve(Type resolveType)
1> : error MSB4018: at React.TinyIoC.TinyIoCContainer.ResolveResolveType
1> : error MSB4018: at React.MSBuild.TransformBabel.Execute()
1> : error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
1> : error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()
1> (default targets) -- FAILED.

[dustinsoftware]

Hi there, I'm not sure if React.MSBuild will work with binding redirects, you might have better luck using a webpack build step instead (see the samples in this repo). Unfortunately I don't have time right now to investigate support for this :/

[Daniel15]

Unfortunately, MSBuild does not easily support assembly redirects. You'd need to add them to MSBuild.exe.config, and they'd affect all MSBuild calls (not just builds of your project).

Having said that, ReactJS.NET does have a super hacky binding redirect for JavaScriptEngineSwitcher. The way it's implemented is that we override AppDomain.CurrentDomain.AssemblyResolve and manually perform the redirect ourselves (c366e3d). We could likely do that for Newtonsoft.Json too. I'm worried about breaking stuff, as that assembly binding stuff is very fragile.

References:
dotnet/msbuild#1309
http://blog.slaks.net/2013-12-25/redirecting-assembly-loads-at-runtime/

[dustinsoftware]

Closing since this question has been answered, feel free to re-open if you'd like some more help.

[ssaroiu]

I'd like to re-open this issue. I have the exact same problem as @jadebayo.

As per this conversation, there are two ways to fix this issue:

1. Add Newtonsoft.Json to the list of assemblies for which manual redirect is resolved by overriding `AppDomain.CurrentDomain.AssemblyResolve' (as per @Daniel15's comment above). I understand this is brittle, but this hack is already present in the code, and it will fix this problem (I checked).

2. If the solution is to use webpack instead (as per @dustinsoftware's comment above), I'd suggest to update the relevant documentation. As is, the documentation for React.MSBuild is silent on webpack. Instead, when I follow the documentation, my build fails due to this bug.

References:
https://reactjs.net/bundling/msbuild.html

[dustinsoftware]

I’ll update the docs, thanks

…

On Wed, Oct 17, 2018 at 13:55, Stefan Saroiu ***@***.***> wrote: I'd like to re-open this issue. I have the exact same problem as @jadebayo <https://github.com/jadebayo>. As per this conversation, there are two ways to fix this issue: 1. Add Newtonsoft.Json to the list of assemblies for which manual redirect is resolved by overriding `AppDomain.CurrentDomain.AssemblyResolve' (as per @Daniel15 <https://github.com/Daniel15>'s comment above). I understand this is brittle, but this hack is already present in the code, and it will fix this problem (I checked). 2. If the solution is to use webpack instead (as per @dustinsoftware <https://github.com/dustinsoftware>'s comment above), I'd suggest to update the relevant documentation. As is, the documentation for React.MSBuild is silent on webpack. Instead, when I follow the documentation, my build fails due to this bug. References: https://reactjs.net/bundling/msbuild.html <http://url> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#512 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5hFuYdMslURmitlgE0l2iduEgxvHH_ks5ul5k8gaJpZM4SMXMm> .

[dustinsoftware]

Also there isn’t a reason we should be stuck to an old Json.Net version, I’ll update that as well On Wed, Oct 17, 2018 at 17:10, Dustin Masters <dustin@dustinsoftware.com> wrote:

…

I’ll update the docs, thanks On Wed, Oct 17, 2018 at 13:55, Stefan Saroiu ***@***.***> wrote: > I'd like to re-open this issue. I have the exact same problem as > @jadebayo <https://github.com/jadebayo>. > > As per this conversation, there are two ways to fix this issue: > > 1. > > Add Newtonsoft.Json to the list of assemblies for which manual > redirect is resolved by overriding > `AppDomain.CurrentDomain.AssemblyResolve' (as per @Daniel15 > <https://github.com/Daniel15>'s comment above). I understand this is > brittle, but this hack is already present in the code, and it will fix this > problem (I checked). > 2. > > If the solution is to use webpack instead (as per @dustinsoftware > <https://github.com/dustinsoftware>'s comment above), I'd suggest to > update the relevant documentation. As is, the documentation for > React.MSBuild is silent on webpack. Instead, when I follow the > documentation, my build fails due to this bug. > > References: > https://reactjs.net/bundling/msbuild.html <http://url> > > — > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub > <#512 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA5hFuYdMslURmitlgE0l2iduEgxvHH_ks5ul5k8gaJpZM4SMXMm> > . >

[ssaroiu]

Both will work for me. How are these two tracked so that I know when they're ready?

Thanks @dustinsoftware.

[kendallb]

I am trying to get the msbuild task working as well. I think the fundamental issue here is that the msbuild DLL is copied into the output directory as part of the reference to the project, when in reality what would work better is for a working version of the DLL and dependent files to be located in a directory in the nuget package, and run from there rather than the developers bin directory? Running it from the bin directory is going to always lead to failures with incorrect DLL's.

I think the msbuild task could be rebuild to work similarly to how the Razor Generator project does it, which is a project I also use that compiles all the cshtml files in my project down to the .cs files, which are then compiled into the project. The source code is here:

https://github.com/RazorGenerator/RazorGenerator/tree/master/RazorGenerator.MsBuild

[dustinsoftware]

I think we can bump the version of JSON.NET that is used internally to avoid this problem. 9 is pretty old at this point.

…

On Wed, Jan 30, 2019 at 22:26, Kendall Bennett ***@***.***> wrote: I am trying to get the msbuild task working as well. I think the fundamental issue here is that the msbuild DLL is copied into the output directory as part of the reference to the project, when in reality what would work better is for a working version of the DLL and dependent files to be located in a directory in the nuget package, and run from there rather than the developers bin directory? Running it from the bin directory is going to always lead to failures with incorrect DLL's. I think the msbuild task could be rebuild to work similarly to how the Razor Generator project does it, which is a project I also use that compiles all the cshtml files in my project down to the .cs files, which are then compiled into the project. The source code is here: https://github.com/RazorGenerator/RazorGenerator/tree/master/RazorGenerator.MsBuild — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#512 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5hFohICK6DecWIUvvxCOICUjazw6ogks5vIoykgaJpZM4SMXMm> .

[kendallb]

It will keep coming up, and if the build dll is referenced from the NuGet location then it also removes the need for extra dependencies to be added to my project bin directory. The way razor does it works nicely.

[ssaroiu]

I agree with @kendallb that bumping out the version number is a band-aid rather than a fix. It'll break again couple of months down the road when Newtonsoft updates their JSON.NET nuget.

[kendallb]

As mentioned, the right solution is to deploy the build DLL into the nuget directory like they do with Razor Generator and run it from there. Then its dependencies are entirely it's own.

[dustinsoftware]

Ok, would you be able to send a pull request? I don’t have time to investigate unfortunately :)

…

On Thu, Jan 31, 2019 at 11:35, Kendall Bennett ***@***.***> wrote: As mentioned, the right solution is to deploy the build DLL into the nuget directory like they do with Razor Generator and run it from there. Then its dependencies are entirely it's own. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#512 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5hFkqJiLGYfUxJyMww7L71I6_cbAjLks5vI0WbgaJpZM4SMXMm> .

[kendallb]

Yeah I am not sure I am going to go this route anyway. I was desperately trying to avoid using node and packages (gah, I don't like node much!), but I think the better solution for our project is to use Gulp to pre-process all our JSX files at build time and then it will also do all the minification and bundling as well. Just have to bite the bullet I guess and get on the node train ...

[dustinsoftware]

Going to roll with bumping JSON.NET to 12 in #779. Apps that still need 9.x can remain on the 4.x branch of this library, which we'll backport fixes to. New features we'll put in 5.x.

[dustinsoftware]

5.0.0-alpha1 preview published to NuGet, please install from there if you need this support ahead of the release.

Cheers