Click here to Skip to main content
15,868,016 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I'm in the middle of working on a .Net Framework (4.7.2) app, and tried to use a library that had some preprocessor symbols in it to handle .Net framework vs .net core usage.

I discovered that the built-in preprocessor symbols do not appear to be defined, in that the following works backwards:
C#
#if NETFRAMEWORK
// this code is disabled (should be enabled)
... some net framework code
#else
// this code is enabled
--- some .net core code (should be disabled)
#endif


If I put a "!" symbol in front of the symbol name, it reverses the enabled/disabled code, as expected, but it's still the opposite of what I should see.

I ended up having to using #if (!NETCOREAPP && !NETSTANDARD).

Might this be caused by the fact that I installed VS2022?

What I have tried:

I've also tried:

0) Exiting VS and restarting
1) Deleting the .vs folder in the project
2) Loading other projects to see if it was project-specific
3) Examining the csproj file, and it correctly identifies .net 4.7.2)
4) Doing a repair on VS 2017
5) Several related built in symbols, such as NET472, NET47_OR_GREATER, and NET20_OR_GREATER.
6) Just to make sure the symbol evaluation was even working, I defined my own symbol TEST_DIRECTIVE, and it did what I expected.
7) Defined my own NETFRAMEWORK symbol, and that seems to be acting as expected.
Posted
Updated 22-May-22 2:02am

1 solution

At a guess - and without access to your system that's all it can be - the NETFRAMEWORK symbol was defined in the build properties for the library module, to build a module that worked for one system but not the other. You already know that preprocessor #IF code is compiled in or not (but others may not, so that why I mentioned it). It's possible that VS2022 changed that build info, but ... if you built the library yourself, you'd need use the project file that came with it to get the right build info.
 
Share this answer
 
Comments
#realJSOP 22-May-22 9:23am    
The csproj file shows <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>, so it seems to me that NETFRAMEWORK and NET472 should be defined. Right?

This is the first time I've ever noticed a problem here.

Also, it's not just the code I'm working on, but even far older projects from 3 years ago that don't seem to like those symbols.
OriginalGriff 22-May-22 10:03am    
THey are only defined if you target .NET Core, apparently:

https://stackoverflow.com/questions/54629452/target-framework-symbol-not-defined

Quite how you are supposed to use them in non-Core apps I'm not quite sure ...
Richard Deeming 25-May-22 5:44am    
According to a comment on that solution:
you can get the symbols to work with .Net Framework projects, but you must use the new .NetStandard project format, and target your preferred .NetFramework version.

If the project is supported, there's a command-line tool to change to the new format:
GitHub - hvanbakel/CsprojToVs2017: Tooling for converting pre 2017 project to the new Visual Studio 2017 format.[^]

Unfortunately, some projects aren't supported. Particularly ASP.NET projects (WebForms, MVC5) and projects with EF6 migrations seem to be verboten.
#realJSOP 25-May-22 7:00am    
Just weird that I can't even use specific .net framework symbols in a .net framework project. You would expect the appropriate NETnnn symbol to be defined in a .net framework project (based on the target net framework version in the project's properties.

Beyond that, all of the projects I've tried it in were actually created with VS2017, so you'd think I'd be all set in terms of project format, right?
Richard Deeming 25-May-22 7:04am    
It comes down to the template; unless you start with a .NET Standard or .NET Core project template, the project file will still be the "old" format.

If you open the csproj file in a text editor, you'll see that new-style projects start with:
<Project Sdk="...">

whereas old-style projects start with:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="..." DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900