SDK style .csproj for .NET full framework
Does anyone know why, when creating a new .NET full framework project, Visual Studio (version 15.9.2) still uses the old style of .csproj file?
To get round this, when creating new full framework projects, I create a .NET core project and then simply edit the TargetFramework tag in the .csproj to target net472 (for example), thereby taking advantage of the new simplified structure.
Does anyone see a problem with this approach?
.net visual-studio
asked Nov 21 '18 at 7:06
Mr DaviesMr Davies
1249
add a comment |
Does anyone know why, when creating a new .NET full framework project, Visual Studio (version 15.9.2) still uses the old style of .csproj file?
To get round this, when creating new full framework projects, I create a .NET core project and then simply edit the TargetFramework tag in the .csproj to target net472 (for example), thereby taking advantage of the new simplified structure.
Does anyone see a problem with this approach?
.net visual-studio
asked Nov 21 '18 at 7:06
Mr DaviesMr Davies
1249
This is still happening in Visual Studio 2019 Preview 2.2.
– Robula
Feb 11 at 9:36
add a comment |
Does anyone know why, when creating a new .NET full framework project, Visual Studio (version 15.9.2) still uses the old style of .csproj file?
To get round this, when creating new full framework projects, I create a .NET core project and then simply edit the TargetFramework tag in the .csproj to target net472 (for example), thereby taking advantage of the new simplified structure.
Does anyone see a problem with this approach?
.net visual-studio
asked Nov 21 '18 at 7:06
Mr DaviesMr Davies
1249
Does anyone know why, when creating a new .NET full framework project, Visual Studio (version 15.9.2) still uses the old style of .csproj file?
To get round this, when creating new full framework projects, I create a .NET core project and then simply edit the TargetFramework tag in the .csproj to target net472 (for example), thereby taking advantage of the new simplified structure.
Does anyone see a problem with this approach?
.net visual-studio
.net visual-studio
asked Nov 21 '18 at 7:06
Mr DaviesMr Davies
1249
asked Nov 21 '18 at 7:06
Mr DaviesMr Davies
1249
asked Nov 21 '18 at 7:06
Mr DaviesMr Davies
1249
asked Nov 21 '18 at 7:06
Mr DaviesMr Davies
1249
asked Nov 21 '18 at 7:06
Mr DaviesMr Davies
1249
1249
This is still happening in Visual Studio 2019 Preview 2.2.
– Robula
Feb 11 at 9:36
add a comment |
This is still happening in Visual Studio 2019 Preview 2.2.
– Robula
Feb 11 at 9:36
This is still happening in Visual Studio 2019 Preview 2.2.
– Robula
Feb 11 at 9:36
This is still happening in Visual Studio 2019 Preview 2.2.
– Robula
Feb 11 at 9:36
add a comment |
1 Answer
1
active
oldest
votes
As to the why, here's an excerpt from a GitHub issue that covers some of it (Add support for ASP.NET (non-Core) projects #2670), albeit specific to an ask regarding ASP.NET, rather than .NET Framework projects in general:
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.
Short version: The new project system isn't mature enough yet to shift over everything, and that won't be a small undertaking when it is.
There's also commentary in there about issues you can have mixing old and new projects in the same solution (which may not be an issue for you, but is worth mentioning for others):
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.
If it works for you, great, but it's not supported and there are definitely pitfalls that you may encounter.
answered Nov 21 '18 at 7:53
RobRob
37.5k21102130
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53406861%2fsdk-style-csproj-for-net-full-framework%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
As to the why, here's an excerpt from a GitHub issue that covers some of it (Add support for ASP.NET (non-Core) projects #2670), albeit specific to an ask regarding ASP.NET, rather than .NET Framework projects in general:
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.
Short version: The new project system isn't mature enough yet to shift over everything, and that won't be a small undertaking when it is.
There's also commentary in there about issues you can have mixing old and new projects in the same solution (which may not be an issue for you, but is worth mentioning for others):
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.
If it works for you, great, but it's not supported and there are definitely pitfalls that you may encounter.
answered Nov 21 '18 at 7:53
RobRob
37.5k21102130
add a comment |
As to the why, here's an excerpt from a GitHub issue that covers some of it (Add support for ASP.NET (non-Core) projects #2670), albeit specific to an ask regarding ASP.NET, rather than .NET Framework projects in general:
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.
Short version: The new project system isn't mature enough yet to shift over everything, and that won't be a small undertaking when it is.
There's also commentary in there about issues you can have mixing old and new projects in the same solution (which may not be an issue for you, but is worth mentioning for others):
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.
If it works for you, great, but it's not supported and there are definitely pitfalls that you may encounter.
answered Nov 21 '18 at 7:53
RobRob
37.5k21102130
add a comment |
As to the why, here's an excerpt from a GitHub issue that covers some of it (Add support for ASP.NET (non-Core) projects #2670), albeit specific to an ask regarding ASP.NET, rather than .NET Framework projects in general:
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.
Short version: The new project system isn't mature enough yet to shift over everything, and that won't be a small undertaking when it is.
There's also commentary in there about issues you can have mixing old and new projects in the same solution (which may not be an issue for you, but is worth mentioning for others):
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.
If it works for you, great, but it's not supported and there are definitely pitfalls that you may encounter.
answered Nov 21 '18 at 7:53
RobRob
37.5k21102130
As to the why, here's an excerpt from a GitHub issue that covers some of it (Add support for ASP.NET (non-Core) projects #2670), albeit specific to an ask regarding ASP.NET, rather than .NET Framework projects in general:
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.
Short version: The new project system isn't mature enough yet to shift over everything, and that won't be a small undertaking when it is.
There's also commentary in there about issues you can have mixing old and new projects in the same solution (which may not be an issue for you, but is worth mentioning for others):
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.
If it works for you, great, but it's not supported and there are definitely pitfalls that you may encounter.
answered Nov 21 '18 at 7:53
RobRob
37.5k21102130
answered Nov 21 '18 at 7:53
RobRob
37.5k21102130
answered Nov 21 '18 at 7:53
RobRob
37.5k21102130
answered Nov 21 '18 at 7:53
RobRob
37.5k21102130
37.5k21102130
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53406861%2fsdk-style-csproj-for-net-full-framework%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
This is still happening in Visual Studio 2019 Preview 2.2.
– Robula
Feb 11 at 9:36