Skip to content
This repository has been archived by the owner on Nov 29, 2018. It is now read-only.

Make the tool here work with apps that target .NET Framework 4.6.1 #128

Closed
Eilon opened this issue May 18, 2017 · 6 comments
Closed

Make the tool here work with apps that target .NET Framework 4.6.1 #128

Eilon opened this issue May 18, 2017 · 6 comments

Comments

@Eilon
Copy link
Member

Eilon commented May 18, 2017

Just like Scaffolding and EF tools already do, we need to make sure that the Razor/MVC view compilation tool works with .NET Framework 4.6.1 apps.

cc @pranavkm @DamianEdwards @davidfowl

@NTaylorMullen
Copy link
Contributor

@bricelam @prafullbhosale What's needed to make a tool work on 4.6.1?

@bricelam
Copy link

bricelam commented May 20, 2017

Here's what we do on EF:

dotnet-ef uses MSBuild to see what the project targets (platform and framework) then launches either:

  • ef.exe for net461 on x64 or AnyCPU. This is compiled as AnyCPU without Prefer 32-bit
  • ef.x86.exe for net461 on x86
  • dotnet exec --depsfile app.deps.json ef.dll for netcoreapp2.0

ef loads the project assembly using Assembly.Load and does its thing.

We shove everything into one package:

  • lib/
    • netcoreapp2.0/
      • dotnet-ef.dll
      • dotnet-ef.runtimeconfig.json
  • tools/
    • net461/
      • ef.exe
      • ef.x86.exe
    • netcoreapp2.0/
      • ef.dll
      • ef.runtimeconfig.json

ef.exe uses an AppDomain to load the project's App.config so any binding redirects get applied.

You may be able to simplify a bit:

  • dotnet-ef and ef could be the same cross-targeted codebase. We separated them because our PowerShell commands call into ef.
  • You don't need to create an AppDomain to get binding redirects. Instead, you can just hook AppDomain.CurrentDomain.AssemblyResolve and ignore the requested assembly's version. We need the full config file because we work with WinForms, WPF & ASP.NET 4

@NTaylorMullen
Copy link
Contributor

@bricelam thanks for the info! Right now this is blocked on the netcoreapp2.0 => netstandard2.0 train. Will re-visit once MVC has been migrated over.

@DamianEdwards
Copy link
Member

This seems very similar to how this tool worked on 1.x. Would we not just bring back the same assets and approach?

@NTaylorMullen
Copy link
Contributor

@DamianEdwards yup, that's exactly what we're doing. I asked for extra information in-case there were additional changes needed.

As for being able to complete the porting of the 1.0 approach, I have the tool in a state that's is a good starting point; however, it can't even restore because it depends on MVC and its chain of dependencies.

@NTaylorMullen
Copy link
Contributor

6e88ea9

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants