Aspnetcore: Support for "classic" ASP.NET

[Kralizek]

I was planning to migrate a couple of ASP.NET 4 projects to the new csproj format but this article says it's not supported.

Is it actually true? If so, it would be a pity since statistically the web project file is where most of our conflicts happen.

Also, current file size: 267 KB...

[guardrex]

That's correct, and [@]DamianEdwards stated in a recent Community Standup that a migrate tool that would help with the process isn't here today but might come later. Nate's blog post is excellent. Since I don't see an issue for future tooling that would help you, you could close here and ask on https://github.com/dotnet/cli/issues/4874, since that issue has some recent activity pertaining to this.

[Kralizek]

A migration tool would be much above my expectations. I would be happy with knowing it is possible to run deploy an ASP.NET 4 application built with the new project.

I already managed to get it to build, it's mostly about packaging, I guess.

[guardrex]

No ... it won't work. I can't point to the exact spot where Damian addresses it; but if you watch the Community Standup from March 14, he answers this question and comments on the possibility of tooling that would help migrate. https://www.youtube.com/watch?v=qlVE5iDjBIg&list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF&index=1

[diegobfernandez]

@DamianEdwards mentions here https://youtu.be/c9Ub4uwjlbo?t=55m8s that Nick Craver did it.
I'm in the same boat as @Kralizek and migrating the msbuild first and move to ASP.NET Core is the best play here.
I don't expect full support. Of course more complex projects may not be able to migrate but some directions would help a lot.

[axelheer]

@diegobfernandez are there any samples on how @NickCraver did it? I didn't find any ASP.NET 4 project based on the new SDKly project format and don't want to waste too much time, if somebody already found a nice solution...

[axelheer]

Okay, something like that can be a start:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>

  <PropertyGroup>
    <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
    <OutputPath>bin\</OutputPath>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNet.Mvc" Version="5.2.3" />
    <!-- ... -->
  </ItemGroup>

  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.Configuration" />
    <Reference Include="System.Web" />
  </ItemGroup>

  <ItemGroup>
    <Compile Update="Global.asax.cs">
      <DependentUpon>Global.asax</DependentUpon>
    </Compile>
  </ItemGroup>

  <ItemGroup>
    <Content Include="Web.config">
      <SubType>Designer</SubType>
    </Content>
    <Content Include="Web.*.config">
      <DependentUpon>Web.config</DependentUpon>
      <SubType>Designer</SubType>
    </Content>
  </ItemGroup>

  <Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" />

</Project>

In order to debug the project, using the "all-new" launch settings is possible:

Problem, so far: IntelliSense for Razor Views expects ASP.NET Core Views, which doesn't make much sense.

[aspnet-hello]

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.

[Kralizek]

Can we reopen this? Supporting pre-core applications should be somehow in the backlog

[Eilon]

@Kralizek I think that it's best tracked by https://github.com/dotnet/cli/issues/4874, as this isn't really ASP.NET-specific.

[Kralizek]

@elion i agree, but there are also asp.net specific issues like the problem of razor validation assuming the core version of the SDK project file is used.

Also, it is to be validated how to properly execute and debug the application during a normal development cycle.

[axelheer]

asp.net specific issues like the problem of razor validation assuming the core version

👍

[NickCraver]

I have an open issue for this in project system land here: https://github.com/dotnet/project-system/issues/2670

[DamianEdwards]

@NickCraver that's the right place for this issue to live. Issues pertaining to specific ASP.NET features of the project system should be tracked in aspnet/Tooling

[Eilon]

Actually, ASP.NET Tooling issues in VS should be reported via VS Feedback.

[DamianEdwards]

@Eilon if that's the case, can we retire that repo? Or does it have another use?

[Eilon]

The readme and issue template say to use it: https://github.com/aspnet/Tooling/blob/master/.github/ISSUE_TEMPLATE.md

But I'll follow up with Tooling folks about what to do with the issue tracker / repo.

[axelheer]

@NickCraver I might point out that "Using F5" is indeed possible (as described above)

The biggest problem (at least for me) is that Visual Studio selects the wrong Razore editor (ASP.NET Core instead of ASP.NET), which makes editing "classic" .cshtml stuff quite impossible. And I've still no idea how to change that...

[Kadajski]

@axelheer did you make any progress on fixing this razor issue? I have found that adding <add key="webpages:Version" value="3.0.0.0" /> to my web.config helps. I get the correct intellisense for the old cshtml now. However the only issue Im having now is purely a code analysis bug it seems. The code analyzers treat the cshtml as a .net core cshtml file still so when the file is open there's loads of errors in the error panel. However when writing code and using the site it all works fine. Just lots of red squiggly lines and errors which sadly is a bit of a deal breaker for me...

Would be good if there was a way to force it to use the correct analyzers. Or even to just disable analyzers completely for cshtml

[axelheer]

@Kadajski nope, I didn't pursue this any further. Thanks for the "webpages:Version" hint!