.net Core 5 X86 X64

[Noreen]

Unlessthere is a reason not to I'd use x64. Gives you access to more memory if you need it. The cost should be the same as all the Azure App Services are 64-bit processors anyway. Compile your code as Any CPU and it run on either. The only time I'd probably drop down to x86 is if I needed to run software that wasn't supported on x64 (say native C++ code that only had x86 libraries).

@Michael Taylor , That is the whole problem. If you check my machine memory which is only 3.5 GB. Now 32-bit allows to use till 3.5 GB only then what is the purpose of x64 .net core runtime at this place.

You're confusing physical memory with virtual memory. x86 is limited to 2GB of user memory (or 3GB with linker option) and 4GB virtual memory total. x64 is 2TB for Win 10 Pro and higher for server. Running an x64 OS allows you to create apps that use more than 4GB of virtual memory. This is important in apps that need lots of memory like games, databases and web servers. It reduces the likelihood of getting out of memory errors.

Because Windows, like most modern OSes, uses paged memory it can swap virtual memory in and out to allow you to address far more virtual memory than you have physical memory. That is what the page file is for. For example I have 32GB of physical memory on my machine but I have running processes that are using much more than that. My SQL Server instance is at 71GB. Again, no real reason not to use x64. It doesn't matter how much physical memory you have. Of course the more the better performance you get.

@KalyanChanumolu-MSFT , Thank you for the reply. Actually why I'm not preferring self contained because it downloads lot of libraries to my local machine and make a package of around 200 to 300 mb in complete.

Now after downloading everything, it occupies lot of space on my laptop which I cannot clean and those extra libraries for self contained will remain in my laptop. The files download somewhere in the depth of my %userprofile% folders and that's the whole issue why I do not prefer self contained.

@Tanul Since @Michael Taylor already answered why you would prefer 64bit, let me clear the confusion you are having about the self contained deployment model.

The files you are referring to are NuGet packages getting downloaded to the cache.

You can easily clear these, read more on that topic here

The entire cache is not included when you publish your app as self contained.

Only the packages referenced within your project are bundled together along with the dotnet framework so that you don't have to depend on runtimes available on the target machine.

@KalyanChanumolu-MSFT , Hmm got it. Thanks. Will explore this stuff. Just one last query. I have checked the link you've shared. What are ready to run images. Technically I understood a little but does they only improve the startup speed or over all application performance as well.

@Tanul R2R is a form of ahead-of-time (AOT) compilation.

R2R binaries improve startup performance by reducing the amount of work the JIT needs to do as your application is loading.

You will find all the information here

Typically with something like this it's specific to the computer being installed on. Some other program or an update has changed something in the registry, a json file or similar that causes the issue.

Usually a second install or manual .net core update fixes things. When/if that doesn't work it's time to make sure all windows updates are present but being this is an end-of-life OS for almost a year and a 10+ year old as well, it might be time to start thinking of upgrading the OS as well to something still getting support and fixes.

Step 2) Create a global.json file at the root of the solution with the exact version number from step 1. it needs to contain all the digits otherwise it wont work. This is the my version at the time of writing

Try running dotnet --list-sdks in the console.According to the info on the pages that appear after downloading .NET Core SDKs from , you need to have version v2.2.106 for VS2017 and v2.2.203 for VS2019.

If you are a Visual Studio user, there are MSBuild version requirements so use only the .NET Core SDK supported for each Visual Studio version. If you use other development environments, we recommend using the latest SDK release.

I had this problem because I uninstalled some older dotnet SDKs. Not only would VS2019 no longer load dotnet core projects, but dotnet was no longer available on my path and so not available on the command line as simply dotnet.

After installing multiple older versions of dotnet and reparing my VS2019 install, I was finally able to fix it by adding C:\Program Files\dotnet\ to my path. Then VS2019 would load the project again.

None of the above worked for me. I noticed that I was having the issue on every type of project, even non-netcore. I was able to use the global.json and get that working. Then I noticed that I had a global.json in a directory further up which was referencing an alpha build of .net core. Deleted that file and bingo no further issue.

I ran into this today, where a solution has some (but not all) the projects using .net core; I had not been into this project in probably a month and had not intentionally done anything with the .net SDKs, so this was a mystery what the heck happened.

A routine install of the latest .NET sdk (3.1.300) resolved this issue, but this feels like really poor behavior of Visual Studio - if it can't find an SDK, maybe tell us which one it's looking for? Ugh.

I spent a full day installing and uninstalling various .net packages and of all the things, that's the one that got it to build....If Microsoft can tell where an error is, why doesn't it just try to resolve it automatically?!

This can happen if you uninstall old versions of .NET Core SDK which all take a lot of space. What happens is the uninstaller removes the PATH entry of the dotnet executable, even the one by other .NET installations, so VS cannot find it. If that is the case, if you type in where dotnet in the terminal, you won't get anything. Find the path to dotnet.exe manually (usually C:\Program Files\dotnet) and add it to PATH. Check in Control Panel whether there is a version actually installed. Make sure to log off and log in again, otherwise it won't work even if you restart VS.

Another possibility is that there is a mismatch between the versions. Type in dotnet --version in the terminal and check the default version. If you get a different version than expected, you can set the exact version you want used by VS by using the global.json file as instructed in other answers.

3a8082e126