Add support for ASP.NET (non-Core) projects

[NickCraver]

We routinely run into cases where the new project system and ASP.NET MVC 5 collide (or rather, don't) - I'd like to see support added. Here are the main use cases I'm aware of, I hope others add more to this issue:

Use Case: Migration

One of the awesome features of the new .csproj system is glob patterns (and Visual Studio not replacing them on every save). This was something we really looked forward to as a real time saver and merge reducer, but in practice we can't use the new project system because a lot of functionality for ASP.NET MVC 5 apps is missing, e.g. even hitting F5 to run it.

When we migrate a large solution to ASP.NET Core, it's a stop-the-world endeavor as are most major changes. Swapping any fundamental framework piece will need to be a big swap, so you want to reduce that window and risk as much as possible. In the case of ASP.NET to ASP.NET Core, you need to swap the project file, all references, port controllers, views, etc. This is a lot to do at once, and every change since you started that path is a royal pain.

A large part of this pain is in the project file itself, since nearly every commit adding or removing files is a merge conflict. And when moving from non-glob to blog worlds, it's a huge pain to manually sync everything into that major change branch.

But why not just stay on non-globs until after the move?

Again, merge pain. A large change like this necessitates moving files around quite a bit and that's the same merge pain between users as exists in 1 world today.

Use Case: Library Projects

We also have several projects that need to support ASP.NET and ASP.NET Core, there are hundreds of thousands of users on the old systems and we need to support them. In the ASP.NET cases specically, we need to have a ASP.NET and an ASP.NET Core sample. In all of these, the only use of the old project system is the ASP.NET (non-core) sample projects. We have to choose between:

• Leave it as the old project system, managing both in different ways forever.
• Screw it, upgrade and host it in IIS, manually attach debuggers, etc.

Adding support for ASP.NET MVC 5 projects for example would help tremendously in porting to ASP.NET Core. In our case, it'd help now for library projects (needed dependencies for main websites to move), and later for those sites like Stack Overflow. We've been working on the .NET Core story for quite a while now, but the daunting task of upgrading the main applications would be made much easier if we could get on the new project system first.

For today examples, I'm using the new .csproj in MiniProfiler and Exceptional MVC 5 Sample projects. The upside is management and simplicity, the downside is users constantly asking why F5 doesn't work. At the moment I'm considering changing them to the old system since the main point of a sample is a bit missed when they can't test it.

Use Case: Immediate

Additionally, it'd just make life easier today in itself, apart from upgrade reasons, by:

• Eliminating most of the cases we run into merge conflicts today
• Make git history usable (e.g. when did we upgrade library X?)
• Reducing project and solution reloads
• Not restarting Visual Studio constant because of the above (this is still faster than reload in VS 2017)

Can we please consider adding support for these project types? Such support would make life easier both immediately and for upgrading in the future.

[NickCraver]

cc @davkean @davidfowl - we've discussed this a bit before as I beat my head on the wall making these things kind-of-work in testing the new system.

[mduu]

One more:
The project files are the files most often result in merge-conflicts because multiple dev added or even renamed files in the projects. Project files are the bottleneck here as most work will result changes in the csproj. Even if the developers work in totally different areas of an assembly chances are high they will get merge conflicts.

[xt0rted]

I'd love to move my projects over to the new system but I'm forced to stay with MVC5 until all dependencies work on .net core as they do today.

Since EF code first migrations don't work with the new system the two projects that would benefit from this the most can't be updated (the website & the DAL). Because of this there's nothing to be gained if I migrate the other smaller projects.

If web projects were supported then one of my two sites could be fully updated, and the other could allow for everything but the DAL project making it worth my time.

[mbp]

For the immediate use case, the new project file format provides some great features such as transitive references. And for some reason, updating packages in a large solution with the old project file format takes ages. Just being able to hand-edit the csproj to update version numbers is one of the best features in it.

[JesperTreetop]

As someone with a lot of MVC5 projects, I have considered migrating them to the new csproj, since there's a lot to like. Since NuGet package scripts don't work, this breaks or at least makes working with Entity Framework migrations an unsupported scenario. (See xt0rted's comment.) They are present in all or almost all of the projects I had in mind, so that's a roadblock. Additionally, some NuGet packages that insert themselves into the build process would probably need to be similarly adapted, not to mention any project-type specific tooling (Microsoft or otherwise).

The features in the new project system would make my life easier - If this could magically be made to work, or if Microsoft would decide to make it a supported scenario and update EF(6) to work (or allow the community to help out), I would consider moving. As an unsupported it-seems-to-work-but-you-break-it-you-bought-it scenario, I wouldn't.

[scottsauber]

At DevIntersection in May it was said by a MS high up in a session that the new project system was coming to older projects by the end of the year this year, FWIW.

[shaggygi]

@scottsauber I seriously don't think this will happen based on this Repo Roadmap for milestone 16.

[dirething]

I have a number of solutions that contain projects that cannot migrate anytime soon as they rely on things like signalR in its current form, MSMQ and EF code first. It would be nice to be able to start new work where possible in the new system until I have the manpower available to rewrite the main components that rely on things the team has decided not to support in a directly upgradeable manner or does not yet support.

The library scenario would at least allow some work to begin moving in the right direction here.

[NickCraver]

Every time we reload the Stack Overflow project (git pull), Visual Studio 2017 crashes. Every single time. Everyone here experiences this, and every time we fix a bug, another pops up later causing the same. While not related directly to this issue, most of the time the project file didn't need to change. Simple support of globs would have prevented the vast majority of reloads in the first place.

Can we please get an idea of if this will happen? It's the most upvoted issue in this repo and causes tangible daily pain. We want to move to ASP.NET Core, etc. but that's going to take probably a year+. I'm sure there are many, many people in the same boat. Please, add support for the current projects most ASP.NET developers are dealing with and will be for some time.

[davidfowl]

Honestly I don't see this happening in the short term (this year). There are lots of kinks to work out with SDK projects and the new project system before we can bring them to older projects. Those kinks don't even have anything to do with ASP.NET so then there would be a bunch of work that needs to happen to port ASP.NET things to the new project system which is non trivial e.g. old razor editor, aspx editor, webforms designer??, build system (WAP projects have a hybrid msbuild + build manager build system), and any other quirks that System.Web requires. Some of those components are written in native code since the older project system was native.

All of this to say, it's not a simple flip the switch, it's the same set of people working on new and existing project systems. When the SDK projects are near flawless, I'd look at bringing it to down level projects.

[NickCraver]

@davidfowl I realize to support everything takes more work, but there's a lot of audience covered with far less than all of that. For example out of that entire list only the old razor editor applies to everything we have. But, I'm not sure what's even required there, as the razor editor appears to work as-is. Not listed is F5 debugging, which today results in:

Unable to run your project. The "RunCommand" property is not defined.

I am using the new project system for sample applications in our library projects because I have to. You can't mix old and new (see migration issues in the initial post here). It mostly works, but you can't F5 it because it can't launch. The editors work. The build works. Everything we need for daily almost works, if only F5 would start and attach. How much work are we talking about to make that work?

We don't have webforms, we don't have .aspx, we don't have build issues with WAP, and apps run fine in all our IIS setups (that's how we have to run them on the new project system). That's passable for sample apps (but really, what choice do we have?) but not for a team working together. I guess I disagree on what the minimum bar is here for a huge daily life improvement.

If F5 worked for spin-up debugging (sometimes attaching isn't practical), we'd have moved over already. What would it take to make this work?

[davidfowl]

It might be acceptable for you but I'm like 85% sure we need to have fully parity before claiming that something is a replacement. Those missing features are probably fine for your development but what about other people? Do we replace the default file new or this is just a hacky edit your csproj and hope it works solution for stackoverflow developers?

If we can't replace the file new project templates for existing ASP.NET 4.x applications then it's not ready yet. You won't believe the sorts of things people rely on Day to day in their projects. Forget those basic features I mentioned, there's also other extensions and features that interact with our project system that would need to work.

That said we could be making incremental progress but it's not a priority. It needs to work well for .net core projects and it really doesn't as yet. There's lots of performance problems that we're actively working on. To expand the scope of the project system before we worked out some of those major kinks would be a disaster

It would be awesome if our web project system was OSS so people could contribute and help make this a reality.

[NickCraver]

@davidfowl We're already in a very hacky state to even think about migrations, anything would be an improvement here. All MS effort appears to be going into a new system we can't realistically migrate to because the old system has been neglected. We have to use VS 2017 for current versions of C#, but to use it with old project systems we're crashing multiple times a day. We can't use VS 2015 unless we want to stick with project.json. We are dedicating our time to libraries on project system in hopes others can use them but we can't even do it ourselves.

We're stuck in a terrible position here. We can't move to the new stuff that works. Efforts to support the new stuff are quite obviously breaking the old stuff and we're suffering for it with zero benefits. I can honestly say: as things stand, we'd have been better off staying on Visual Studio 2015. Yes, I mean that. But it's too late to go back without significant work, we now use a C# version it doesn't support pervasively.

There is no incremental migration story. The solution is all or nothing at the moment due to the new project system not supporting all the projects people already have. dotnet msbuild is the same story, since it can build new things but not old projects.

And let's not forget the clock is ticking. It's already been said that ASP.NET Core 3.0 will drop .NET Framework support and move to .NET Core. This means we have a time limit on an incremental migration story that we can't even begin yet. Due to issues like this migrations to ASP.NET Core remain a logistical nightmare. My teams are asking when we can upgrade and I don't have an answer for them because of these blockers.

[davidfowl]

All MS effort appears to be going into a new system we can't realistically migrate to because the old system has been neglected

That's very far from the reality of the situation. I'm going to guess you're specifically talking about SDK projects and nothing more. PackageReference was actually ported to the old style csproj without requiring the use of SDK projects.

We have to use VS 2017 for current versions of C#, but to use it with old project systems we're crashing multiple times a day.

That sucks. I can't speak for what changed here that's causing the existing project system to crash multiple times a day. I assume you've given dumps to the appropriate people and they're looking at it?

We can't use VS 2015 unless we want to stick with project.json

This is confusing? Are you using both .NET Core projects and .NET Framework projects in the same solution? Is that the issue you're facing right now?

We're stuck in a terrible position here. We can't move to the new stuff that works. Efforts to support the new stuff are quite obviously breaking the old stuff and we're suffering for it with zero benefits.

Do you mean that you can't move new projects to ASP.NET Core or .NET Standard because it requires the new project system? Can you be more specific here?

There is no incremental migration story. The solution is all or nothing at the moment due to the new project system not supporting all the projects people already have. dotnet msbuild is the same story, since it can build new things but not old projects.

Yes this is true and I don't see this changing for a while. Changing all of the old things to the new project system will take years. Certain project types will be easier than others but it's not easy changing them all with full parity (see roslyn 😄 for a similar story, that took ~5 years).

And let's not forget the clock is ticking. It's already been said that ASP.NET Core 3.0 will drop .NET Framework support and move to .NET Core.

That's absolutely false, that was never said. The thread that got out of control made tons of assumptions that maybe that was one of them. Nobody from Microsoft said that ASP.NET Core 3.0 is absolutely dropping .NET Framework support.

Some questions for my education:

• What are the big things you are struggling with at the moment?
• Why is supporting is ASP.NET 4.x with an SDK project a stepping stone to ASP.NET Core support?
• Why can't you use both ASP.NET Core and ASP.NET in the same solution?
• Do you have .NET Standard libraries that are shared between old and new?
• Can you list out some of the pains you have migrating (any pains really)?

[NickCraver]

I'm going to guess you're specifically talking about SDK projects and nothing more. PackageReference was actually ported to the old style csproj without requiring the use of SDK projects.

Correct, talking about this area. <PackageReference> is a great concept, but broken in the older world. It took us a full day to get a build setup and working on and decided against attempting it with any further ASP.NET non-Core projects. We can use it in libs, that's it.

I assume you've given dumps to the appropriate people and they're looking at it?

For all but the latest yes. We've hitting yet another crash in the new preview. We're hopeful when hitting the update button that things will improve from one preview to the next but honestly it's 50/50. From a time standpoint though, we can only invest so much. We need to do our work, not fight with Visual Studio all day.

Do you mean that you can't move new projects to ASP.NET Core or .NET Standard because it requires the new project system? Can you be more specific here?

We can't move because we can't even start to move the solutions. We can't move things to libraries on the new system and migrate over in any reasonable way, because the build system won't build both. And there's a big mismatch on server build tools and what Visual Studio does here (see the fights we had with it above). Side note: those server build tools aren't labelled with a version.

Yes this is true and I don't see this changing for a while. Changing all of the old things to the new project system will take years. Certain project types will be easier than others but it's not easy changing them all with full parity

Sure, but this isn't asking for full parity on day one. By removing the biggest blockers to starting migration on the way to parity, we can parallelize a lot here and end up with ASP.NET Core far sooner.

That's absolutely false, that was never said.

I'm fairly certain this was said in a community standup around the time all the changes were happening as the current thinking. If that's changed then great, but we've got no newer information AFAIK.

What are the big things you are struggling with at the moment?

I'm assuming you mean in trying to make this work. Building (on a server, not in VS) and debug launching are the big 2.

Why is supporting is ASP.NET 4.x with an SDK project a stepping stone to ASP.NET Core support?

Because you can't mix both styles in the same solution and have the tooling work (at least today). The project files are massive today (no globs), so it's a big bang change to move everything over. It also means we can't move to anything with the dotnet build system. dotnet build and dotnet msbuild both go boom with these project types.

Why can't you use both ASP.NET Core and ASP.NET in the same solution?

See above.

Do you have .NET Standard libraries that are shared between old and new?

We want to, but again, see above. The only things we can share are completely external to the solution (e.g. MiniProfiler, StackExchange.Redis, Exceptional, Jil, protobuf, etc.). Moving code outside of the solution that belongs to it in order to make the builds work would make dev time take even longer (e.g. unnecessary packages, publishing, and build time for every minor change).

Can you list out some of the pains you have migrating (any pains really)?

The above covers it mostly. We can't use dotnet msbuild to build solutions if they contain old project types, so we can't go there. We can't use globs because VS will replace them. And crashing on every project reload is just maddening, since it takes 60-120 seconds per restart of Visual Studio for it to becomes responsive again. I'd estimate at this point in time I'm losing about 30 to 40 minutes a day on Visual studio locking up (for over a minute at a time) or restarting due to a crash. And losing project file changes when it does that.

I'm happy to work with someone and send our solution over (NDA style) if it'll help.

[davkean]

@NickCraver I've reached out to you privately on the crash you are experiencing. The long delays are likely caused by a mix of slow design-time builds + the fact that we block the UI while waiting for them in the legacy project system. This experience should be much better in 15.5 as we've done some performance here to reduce the number of builds we do during solution load/reload/configuration change. If you have custom targets, I'd use the steps called out in the doc to make sure that they aren't increasing your design-time build time. Performance work we're doing for .NET Standard/.NET Core scenarios will also benefit these builds for legacy scenarios.

Our intention, long term, is to have feature parity with the legacy project system, however, our biggest focus for the next couple of updates is to improve the performance and reliability of the existing scenarios we've already bitten off.

Can you expand on the the "all or nothing" argument? You can continue to call msbuild solution.sln on solutions that have a mix of both legacy format and sdk-based format. Moving over to dotnet build isn't a requirement. Is it because you don't want to update the build server?

[davidfowl]

I'm fairly certain this was said in a community standup around the time all the changes were happening as the current thinking. If that's changed then great, but we've got no newer information AFAIK.

Nope, it was never said and nothing changed.

Correct, talking about this area. is a great concept, but broken in the older world. It took us a full day to get a build setup and working on and decided against attempting it with any further ASP.NET non-Core projects. We can use it in libs, that's it.

It would be good to get more feedback here. Was the entire experience just error prone or were there specific issues?

We can't move because we can't even start to move the solutions. We can't move things to libraries on the new system and migrate over in any reasonable way, because the build system won't build both. And there's a big mismatch on server build tools and what Visual Studio does here (see the fights we had with it above). Side note: those server build tools aren't labelled with a version.

Like @davkean asked, why can't you even begin to move? MSBuild 15 supports both old and new project types AFAIK, you can't use dotnet build but msbuild should work. If the build tools don't have an msbuild 15 equivalent then we suck and should have that.

Sure, but this isn't asking for full parity on day one. By removing the biggest blockers to starting migration on the way to parity, we can parallelize a lot here and end up with ASP.NET Core far sooner.

The issue is asking for "support" we can't add a fraction of the features and claim support. Support means full parity. Like I asked before, knowing what specifics are absolutely blocking you from beginning the migration would be extremely useful.

Because you can't mix both styles in the same solution and have the tooling work (at least today).

This is the real crux of the issue. We need to figure out why this isn't working. Can you list out the issues with this? This absolutely needs to be fixed because this is key to people migrating existing solutions.

The project files are massive today (no globs), so it's a big bang change to move everything over. It also means we can't move to anything with the dotnet build system. dotnet build and dotnet msbuild both go boom with these project types.

This isn't new and shouldn't be a blocker. MSBuild should work like it always did with both existing and new style SDK projects.

We can't use dotnet msbuild to build solutions if they contain old project types, so we can't go there.

Can you just use the latest msbuild on windows?

We can't use globs because VS will replace them.

This isn't new and I don't see how it's a blocker. Over time more projects will likely be converted when full parity can be reached, but it's not a short term thing.

[jmarolf]

Correct, talking about this area. is a great concept, but broken in the older world. It took us a full day to get a build setup and working on and decided against attempting it with any further ASP.NET non-Core projects. We can use it in libs, that's it.

Adding @tmeschter. This sounds like a bug in PackageReference that we should fix. @NickCraver can you describe what the issue is in more detail?

[NickCraver]

@davkean @jmarolf

I've reached out to you privately on the crash you are experiencing.

Thanks! I've followed up and have many dump ready to send from hangs, stalls, and just-before crashes today.

Can you expand on the the "all or nothing" argument? You can continue to call msbuild solution.sln on solutions that have a mix of both legacy format and sdk-based format. Moving over to dotnet build isn't a requirement. Is it because you don't want to update the build server?

We have no problem updating the build servers (we control them all), but updating to the latest MS Build tools released we never got to work. We were deploying manual target directories and overrides to get web applications working. To make a single project work, we ended up copying all targets from local installs over to a directory on each build server and overriding the targets path in MSBuild. The new build tools installed fresh did not work for web applications (missing their targets).

On the mixing: we could never figure out how to build it. See opserver/Opserver@7ccf72f for similar issues on finding MSBuild itself. dotnet build is a great advancement to all these things (e.g. tremendously simplified builds), but is completely unusable for most current scenarios.

The major blocking problem we had (I'll have to re-attempt this with another solution to fully document as we go, trying from recall here) was various breaks on the new project system with old references. All the tooling either created or expected <PackageReference>, or we ended up with 2 very different references on the machine since these 2 cannot point to the same DLLs. Our private projects cannot use <PackageReference> if they contain references to our authenticated NuGet feeds (the long standing reason we have to check in /packages). Almost all projects have such references. I admittedly last tried mixing <PackageReference> and old style path references in a solution 3 previews ago, but I haven't heard of any changes here, or even whether this is an expected scenario. NuGet tooling doesn't seem to expect this scenario I'm guessing.

In short, there are several areas where bridging old and new worlds is painful or just something we couldn't make work. The authenticated feeds issues is hard for me to demonstrate in open source, unfortunately.

[NickCraver]

@davidfowl Thanks for the replies, follow-ups:

Nope, it was never said and nothing changed.

Fair enough, if so that's my mistake, I swore this was said off-hand but maybe it wasn't by the team. My fault.

If the build tools don't have an msbuild 15 equivalent then we suck and should have that.

I'm honestly not sure what the contain. 15 to 15.3 had breaking changes you needed a newer version for, and installing the latest didn't work. I'll try a single new project in the SO solution soon as I'm able (likely next week, we're busy as hell atm) and better document step by step what breaks. See above response for some of the issues I can recall right now.

The issue is asking for "support" we can't add a fraction of the features and claim support. Support means full parity. Like I asked before, knowing what specifics are absolutely blocking you from beginning the migration would be extremely useful.

Again see above. Note: we're not asking for support (the official term), only bits that would unblock many. We built Stack Overflow on an MVC beta, test SQL in CTP in production, etc. no strangers to pre-release bits on the way to supported.

This is the real crux of the issue. We need to figure out why this isn't working. Can you list out the issues with this? This absolutely needs to be fixed because this is key to people migrating existing solutions.

Yep, above. I'll do a full doc run on an SO branch with the current preview and build server tooling to see what we hit today (AFAIK nothing has changed, we were on the latest build server tooling on the last attempt), and write up what we're hitting. I don't want to mis-file a dozen issues though, how about I file a big one and we break it out into areas as you guys and gals see fit? If so: which repo?

Can you just use the latest msbuild on windows?

I think so, but these aren't versioned like they need to be IMO. I'm both a developer and a sysadmin, and the sysadmins here are frustrated at the tooling downloads. For example go here and scroll to the bottom: https://www.visualstudio.com/downloads/ It's an unversioned installer (that needs an update immediately after downloading by the way, not an awesome experience). Since it's unversioned, we have to make some assumptions about which version is installed or blindly update it (current approach) which led to some mismatches of 15.0 vs 15.3 msbuild installs. Just for fun, it's not in the registry anymore either, so we have to install a whole other project just to find it (vswhere), and I guess check that into git or PATH it on every server (is this sounding crazy yet to do a simple build? it is to me).

In the old world we could at least find where MSBuild is in the registry (in a PowerShell build script) and move along. Now even that's regressed. This isn't an issue if you're using dotnet build, but is if you need actual full msbuild. I consider this a regression, you now need extra tooling just to find MSBuild.

But yes, we're free to use the latest version of MSBuild. Actually figuring out how to do so, which version is installed or where it is are all different questions we don't always know the answer to.

This isn't new and I don't see how it's a blocker. Over time more projects will likely be converted when full parity can be reached, but it's not a short term thing.

That's unfortunate. When we heard about the new project system it was the thing we were all excited about, because it results in the most pain. From an outside perspective (and maybe mine's way off) I don't believe that new project system being only for new projects/types was communicated well at all. It was a major let down to realize this was the case and now will be for quite some time.

Still, I'll help debug here where I can but admittedly have practical time limits on fighting tooling vs. getting any work done. Most of this is done on my personal time at the expense of our OSS getting any love.

[tmeschter]

@NickCraver

1. I'd like to hear more about the issues you've had with <PackageReference> on the old project system as I implemented that. :-)
2. I'm also interested in any crashes that occur in VS 2017 when using the old project system. In general I would expect 2017 to be more reliable in this area, and regressions are a high priority.

Feel free to ping me directly at [email protected].

[jmarolf]

@NickCraver regarding the other issues:

1. MSBuild tools does not include the targets to build web projects
2. Unable to locate MSBuild on build server.

The first issue sounds like a bug, but I'm confused. It looks like you can install the web targets:

@NickCraver does this not work? I understand automated installation of this installer leaves some things to be desired but the following command should work

vs_BuildTools.exe  --layout c:\vs2017buildtools --includeOptional --lang en-US

Giving you a folder (C:\vs2017buildtools) with vs_BuildTools.exe that you can copy and install on any machine. while guaranteeing a known version Is this not what you are doing?

The second issue is a general problem with everything in vs being harder to find because you can now install vs anywhere. However, you can control where things get installed on your build server. If you always install the build tools to C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools msbuild will always be under C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin

[NickCraver]

@jmarolf Here's what we ended up with to get building and not have gigs of extras to maintain and update (lengthening patch times). Tooling offline creation:

.\vs_BuildTools.exe  --layout \\path --includeOptional --lang en-US
  --add  Microsoft.VisualStudio.Workload.NetCoreBuildTools 
  --add  Microsoft.VisualStudio.Workload.WebBuildTools
  --add Microsoft.VisualStudio.Workload.MSBuildTools
  --add Microsoft.Net.Component.4.6.TargetingPack

Server install/update:

.\vs_BuildTools.exe --includeOptional 
  --add  Microsoft.VisualStudio.Workload.NetCoreBuildTools
  --add  Microsoft.VisualStudio.Workload.WebBuildTools
  --add Microsoft.VisualStudio.Workload.MSBuildTools
  --add Microsoft.Net.Component.4.6.TargetingPack
  --noWeb 
  --passive

The second issue is a general problem with everything in vs being harder to find because you can now install vs anywhere. However, you can control where things get installed on your build server.

Sure, I agree. But in open source we don't control the build server. Thousands of people control thousands of build servers.

This week we've had several major issues with Stack Overflow (including 2 outages) rooted in bad .csproj merges that could have been globs for the past decade if the tooling stopped expanding this. Is there any hope of not expanding globs at least being supported on the old system? We're far from the only ones hitting this. Or is the stance this is so far into the future it'll never happen and I should just close the issue?

[Pilchie]

We don't currently have work to support not expanding globs in the old project system on our radar. Instead, we'd like to eventually be able to open old style projects with the new project system without also needing them to be converted to SDK projects.

[NickCraver]

@Pilchie As an illustration of why this matters:
Our main project (StackOverflow.csproj) using only globs goes from 13,307 lines down to 1,537 lines. Of those 1,537:

• 900 are view/model nesting we use (this could be 1 pattern if Related files support #159 gets in)
• 363 are refs.

With <PackageReference> (which we can't use due to NuGet server issues yet - unrelated to this issue), that 363 goes down to 122 lines.

So any, with globs something we experience merge pain with multiple times a week goes to nothing. I looked through our git history and I believe we would have had a merge conflict only once in the past 6 years (one simultaneous lib update race) in our main .csproj. That's a huge impact to our daily lives and to the stability of our code, application, and sanity.

Please, reconsider some measures to improve life for all of the developers who are dealing with ASP.NET non-Core and will be for the foreseeable future. There are millions of us and eventually is a long time.

This is by far the highest voted issue in this repo, so I'm curious: how is work and feedback prioritized? The User Voice forums for Visual Studio are, and I don't think I'm being extreme here, a wasteland. They're not maintained, there's a lot of duplication, and User Voice has no mechanisms for keeping up with issues. While problems are getting love in the new developer community site, missing things (like this) are closed as non-problems and the customer avenues for making suggestions are pretty grim. It's not specific to this issue, but as this is by far our biggest desire to improve every dev here's daily life, I'm asking.

Note that Visual Studio is crashing on .csproj changes/reloads on a git pull more often than ever. I'm seeing many of my teammates experience this on hangouts several times a day. So this issue (or even just globs) would have a very significant impact on developer frustration (by not prompting for reloads). We're seeing new project types get support and love while those of us in the old world are just crashing. It's very demotivating to hear "eventually" on improvements while this trend is continuing.

Please, please prioritize this.

[mduu]

If I have to vote for one single thing, I like to get rid of all the individual file-references in our MVC5 project files (and class-libraries). They result in merge-conflicts in every other PR.

Note: we can't move to .Net Core for the next years as our hoster/customer (federal gov.) does not have any plans to support .Net Core yet. That will take years then.

[davkean]

@NickCraver The crash when the csproj reloads we should look at. You've mentioned this before but I'm yet to see feedback reports from your team about it - can you get them to individually report issues (you don't need to catch the crash, just report that it occurs) and we'll go through the watson reports to see what the underlying cause is?

Understand the pain here here with merging, but as @Pilchie mentioned we have no intention of supporting globs in the old project system. The work there is much harder than the new project system due to it being native (and we have double-wrap all the new globbing-based APIs from MSBuild) and unlike the new project system it has its own in-memory model of the project separate to the MSBuild model. We would rather spend that time and resources on adding features to the new project system that will enable you to move your existing projects over to it.

[bartlomiejmucha]

@brad-jones @CZEMacLeod
I failed to migrate our solution because of the issue with dlls that are not in bin folder, but in the root folder. I mentioned that in the comments above.
Out of curiosity, does it work correctly for you? Are the dll files published to bin folder for you?

[brad-jones]

Yeah @bartlomiejmucha, running dotnet build ./path/to/<name>.csproj spits out a full build into bin/ as I'd expect.

[brad-jones]

FWIW the following VsCode launch config worked for me. I'm pretty happy, now I can dev on the old stuff without having to fire up full on VS.

{
    "configurations": [
        {
            "name": "IIS Express",
            "type": "clr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "C:\\Program Files\\IIS Express\\iisexpress.exe",
            "args": [
                "/path:${workspaceFolder}\\project\\Payroll.Timesheets.Web",
                "/port:51867"
            ],
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            },
            "cwd": "${workspaceFolder}/project/Payroll.Timesheets.Web",
            "serverReadyAction": {
                "pattern": "Successfully registered URL.* \"(https?://\\S+|[0-9]+)\"",
                "uriFormat": "%s",
                "action": "openExternally"
            }
        }
    ]
}

[Mek7]

I'm trying to convert our ASP.NET MVC5 project to sdk-style, while still targeting net48 (we will move it to .net 8 later). I tried the MSBuild.SDK.SystemWeb by @CZEMacLeod and the project compiles fine, but I am unable to run or debug it from VS. We use and want to use full local IIS, not IIS Express. The error is:

Unable to run your project. The "RunCommand" property is not defined.

To get the project to debug, I have to attach to process w3wp.exe which is very cumbersome. I would like to preserve developer experience of just pressing the Run or Debug button, which opens the browser with website from local IIS. I think that launchsettings.json needs to be configured somehow to do this automagically, but is it even possible?
P.S.: this was no different before using the MSBuild.SDK.SystemWeb so I'm not sure if I should keep that SDK or revert to the previous one - Microsoft.NET.Sdk.Web

[CZEMacLeod]

@Mek7 It is certainly possible to use MSBuild.SDK.SystemWeb to have the F5 experience with IIS Express. I'm not entirely sure if it would work with IIS full or not.

Is there a specific reason for not using Express for development reasons? I used to use the full version for a long time, but switched to express as it was easier to manage.

The MSBuild.SDK.SystemWeb.Templates project includes blank templates which include F5 with IIS Express functionality. I would recommend starting with one of those and then adding in the rest of your existing project and settings.

I think if you change the IIS Express profile name and command to just IIS it should work though.

[Mek7]

@CZEMacLeod thank you for your answer.
I don't know why we use Local IIS instead of IIS Express, it's always been like that here where I work... changing that now may be a hassle not worth doing when it is only temporary... (until all projects are migrated to .net 8).
Yes, what I did was change commandName to "IIS" but in launchsettings.json but it made no difference.
So far I decided to stay away from this sdk project migration of web projects. I thought it should be easy as other project types were. It will be easier to do this when the whole project is migrated to .net 8 at once.

[dirething]

@Mek7 IIS and IIS express did not always work the same way for some specific scenarios like custom handlers, security or anything else tying into the very early events in the request lifecycle. Some of those things did not work in IIS express as they would in IIS and others would give you different results under debug depending on which host they were under.

While this has improved over the years it is still not fully gone so YMMV on how successful moving to IIS express would be. If your project is old, or uses older components or if the project has a lot of low level custom handlers it may very well be that way for a very good reason.

[AlleSchonWeg]

Hi,
is it possible to add the template for a new Web Form item. In the Add --> New Item... (Ctrl+Shift+A) dialog i have only MVC, API etc. but no items for web forms:

I tried <Project Sdk="MSBuild.SDK.SystemWeb/4.0.88"> and <Project Sdk="Microsoft.NET.Sdk"> and <Project Sdk="Microsoft.NET.Sdk.Web">

[CZEMacLeod]

@AlleSchonWeg You could copy the default templates into the sdk templates if you want. I'd happily accept a PR for that, although it is not the best for handing new code in webforms as it doesn't easily hook-up new components and events etc. due to the limitations of the IDE.

[ericoporto]

I see this is still in backlog with no due date, is there any hope this will be pick up in 2025?

[jrmoreno1]

@ericoporto : probably slightly better than bring back VB6. I would love to see it, there are in my opinion a significant number of web forms and mvc that could benefit from tooling improvements, but realistically it won’t happen without a change in priorities and I don’t see that happening. Things are actually going in the opposite direction with more encouragement to upgrade to the latest and greatest framework version.

[davidfowl]

I see this is still in backlog with no due date, is there any hope this will be pick up in 2025?

This isn't currently planned no. My gut says no, this will not be done in 2025. No promises though.

[davidfowl]

That said, this issue has the most engagement in this entire repo (based on my analysis...)

[Happypig375]

well, @davidfowl should consider hiring @CZEMacLeod for MSBuild.SDK.SystemWeb then 🙂

[NickCraver]

I would say this is still worth doing - we can't use dotnet build and friends because of this - until the last ASP.NET project is moved. Since ASP.NET projects tend to be the leaf projects, we're 100% on old paths. As more enhancements are made for various dotnet * tooling more and more team productivity is on the table.

[davidfowl]

A reasonable middle ground might be figure out the work required in tooling to make @CZEMacLeod's MSBuild.SDK.SystemWeb work as well as it can.

[chucker]

A reasonable middle ground might be figure out the work required in tooling to make @CZEMacLeod's MSBuild.SDK.SystemWeb work as well as it can.

I believe that project needs some hooks from VS, e.g.

• enable web publish
• show designer / updater designer code files when editing aspx

[davidfowl]

enable web publish

Does not sound crazy.

show designer / updater designer code files when editing aspx

This feels like a BIG stretch.

[NickCraver]

At least for the cases I've seen, being able to just build would be a huge advancement as it allows an entire build system and everything related to move forward. If you need the full VS/editing experience, then I think that lift likely isn't worth doing.

There's a whole category of solutions with other projects moving forward, ASP.NET APIs that don't have any views, etc. that would benefit from the base essentials working without MSBuild and if that's doable reasonably, I very much support that effort and would be happy to help test any iteration of it.

[davidfowl]

You mean build and run/debug right? What are the gaps in @CZEMacLeod ‘s sdk?

[NickCraver]

Mainly that we can't build with dotnet build (so dotnet test, etc. unless MSbuild + --no-build, etc.), example:

➜ msbuild src\Hosting\Azure\HostRole\Api\Microsoft.Web.Hosting.HostRole.Api.csproj
MSBuild version 17.12.12+1cce77968 for .NET Framework

  Microsoft.Web.Hosting.HostRole.Api -> Q:\ms\Antares\2\out\debug-amd64\Microsoft.Web.Hosting.HostRole.Api\Microsoft.Web.Hosting.HostRole.Api.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:22.52

➜ dotnet build src\Hosting\Azure\HostRole\Api\Microsoft.Web.Hosting.HostRole.Api.csproj
Restore complete (1.6s)
  Microsoft.Web.Hosting.HostRole.Api failed with 1 error(s) (0.0s)
    Q:\.tools\.nuget\packages\msbuild.sdk.systemweb\4.0.79\Sdk\Sdk.targets(31,3): error MSB4019: The imported project "C:\Program Files\dotnet\sdk\9.0.101\Microsoft\VisualStudio\v17.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\9.0.101\Microsoft\VisualStudio\v17.0\WebApplications\Microsoft.WebApplication.targets" is correct, and that the file exists on disk.

Build failed with 1 error(s) in 2.3s

In our case, we don't even need the debug and build alone would be a huge win, but that's certainly biased and I'm not sure what the percentages are there. It's entirely possible that either of these aren't hard to solve...or that they're deep rabbit holes.

[CZEMacLeod]

@NickCraver @davidfowl This is because of the 2 files that are part of Visual Studio that are used as part of the build process for Web Application Projects.
In my case they resolve to:

• C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VisualStudio\v17.0\WebApplications\Microsoft.WebApplication.targets
• C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VisualStudio\v17.0\WebApplications\Microsoft.WebApplication.Build.Tasks.dll

The problems are
a) These are part of VS and I don't want to embed them in the SDK as I'm sure they are copyright.
b) This also pulls in C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VisualStudio\v17.0\Web\Microsoft.Web.Publishing.targets from a similar directory and that has various DLLs too.
c) These DLLs target NET Framework.

It does resolve the intial path using $(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets, and I guess I could make it check if the path existed before import, but I don't know exactly how important it is to the build and/or publish process.
That file resolves the rest using $(AspNetTargetsPath)Microsoft.Web.Publishing.targets

There was some experimentation done early on in the project trying to use dotnet build CZEMacLeod/MSBuild.SDK.SystemWeb#1 (comment) but it was unsuccessful.

I know there is a few nuget packages out there which package these files (under the idea of being useful for build servers without the ASP.NET workload installed) - but as I said, I didn't want to include anything copyright / part of VS in the package.

Example: MSBuild.Microsoft.VisualStudio.Web_WebApplication.Targets although it is a very old version.

I think part of these targets do the XSD transforms (similar to the slow-cheetah project) that apply the Debug/Release and/or Publish Target web.config transforms.

With actual input from Microsoft I'm sure all of this could be resolved pretty easily (even the designer hookup stuff could probably be pretty quickly resolved based on enabling for a ProjectCapability). We already added LegacyRazorEditor to make razor work so I'm sure we could get webforms sorted too if there was enough interest.

Note - I just tried the test from the comment above but with VS2022 installed. As long as you use the latest version of the compilers package etc. (which no longer us CodeTaskFactory) the following works. You can use a BuildTools install instead of the full version. You can set VSToolsPath using the envvars script or VSWhere and then you don't even need to add the property and restore etc. work as expected.

mkdir test
cd test
dotnet new systemwebfull
dotnet build -p:"VSToolsPath=C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VisualStudio\v17.0"

Restore complete (0.3s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  test succeeded (4.9s) → bin\test.dll

Build succeeded in 5.9s

[julealgon]

show designer / updater designer code files when editing aspx

This feels like a BIG stretch.

@davidfowl pretty sure that's not a showstopper though. It's just an annoyance for new development after the conversion.

---

In our case, we don't even need the debug and build alone would be a huge win

We are on the same boat as @NickCraver : just being able to use dotnet CLI against these projects would be absolutely game changing for us as we could then move our entire solution into a much simpler CI/CD pipeline. We are currently maintaining a nasty legacy CI/CD system using Cake that would be completely streamlined if dotnet CLI was an option.

[chucker]

pretty sure that's not a showstopper though.

It's not, for the most part, but I'm a bit surprised/curious. The way we work around this for now is to have an Sdk-style project as well as a classic-style one, and manually keep those in sync if we need to make changes to aspx files that produce changes to designer files.

I figured what's needed to tell VS to generate the designer files is something like a ProjectCapability or a ProjectTypeGuid.

Note that I'm not asking for this to work in the .NET Core version of MSBuild, just within an Sdk-style project. As I understand it, when using WindowsDesktop (WinForms, WPF) projects with an Sdk-style project but a 4.x TFM, Visual Studio will automatically use the .NET Framework version of MSBuild; for example, things like SGen and LC are available and work.

[objecttothis]

We have run into the same problems already reported (designer files not automatically updated, debug doesn't work out of the box, no web forms templates, no intellisense support). I have been manually updating designer files and cloning existing web forms then refactoring. To get debugging to work you can, build, open a page in your web browser (I'm using Firefox Developer Edition) then go to Debug > Attach to Process and select w3wp.exe. It will then start the debugger and I've been able to step through my code as before. On these projects our TargetFramework is net48.

[jrmoreno1]

@davidfowl :

A reasonable middle ground might be figure out the work required in tooling to make @CZEMacLeod's MSBuild.SDK.SystemWeb work as well as it can.

Do you mean mean make it work better (MS employees contributing to @CZEMacLeod 's repo) or pull it into MS? Leaving it where it is with MS contributing would not help many people, pulling it into MS and labeling it experimental or preview, would help a lot more.