Where to install nuget package?

Jan 30, 2015 at 5:49 PM
I have two assemblies, my "main" project, and a project with "shared" views.

I understand that the Visual Studio extension's purpose is to compile from ".cshtml" to ".cs". It works in both projects automatically.
  1. But where does the nuget package need to be installed? Only in the shared assembly, or in both?
  2. What is actually its purpose, is it simply to make the main project know about the compiled views in the shared one? In which case, if I only have one project, do I even need the nuget package?
Coordinator
Jan 30, 2015 at 6:08 PM
RazorGenerator.Mvc contains the PrecompiledMvcEngine and related things, which are needed for it to work at runtime. It should be added to whichever assembly registers the view engine (search for PrecompiledMvcEngine).
Jan 30, 2015 at 6:13 PM
Edited Jan 30, 2015 at 6:14 PM
I added the nuget package to the "shared" project, which has my shared/reusable views which I use in multiple projects.

I assume you mean that I don't need it in the client/dependent/child/MAIN/whateveryouwanttocallit! project as well? That's what the documentation seems to indicate, but it's not 100% clear (to me!).
Coordinator
Jan 30, 2015 at 6:19 PM
There are multiple models for doing the engine registration, either externally or from the assembly itself. Simply put, you need it wherever you do the registration. Just try removing it, and if it still builds, you didn't need it :)
Jan 30, 2015 at 6:19 PM
I see there is also documentation on your blog. It says there:
"Now the fun part begins: using NuGet, install the RazorGenerator.Mvc package into your class library. This adds a number of things to the project:"

So I am assuming the nuget package goes into the shared assembly, not the main one.

There's actually a lot of good info in that blog article, pity I didnt see it before.
Jan 30, 2015 at 6:24 PM
Edited Jan 30, 2015 at 6:24 PM
davidebbo wrote:
There are multiple models for doing the engine registration, either externally or from the assembly itself. Simply put, you need it wherever you do the registration. Just try removing it, and if it still builds, you didn't need it :)
Haha! Yes figuring out a API by the "try see if it builds" method, is something I do too! Frowned upon but hey it works.

Didnt realise you can register it in a client project, as its not in the docs. But I think registering it in the shared assembly makes more sense (in my use case I suppose), because then it is self-registering, and is mroe reusable, like your blog article explains.

Thanks