Develop Reference

Backward .NET compatibility for NuGet packages?

I'm accustomed to the Java world: it's generally safe to run an application on a newer JRE that has dependent .jars compiled with older versions of Java.
.Net is a bit stricter. For example, if I build an ASP.NET app with TargetFramework "netcoreapp3.1", then I MUST install ASP.Net Core 3.1 runtime on every host server I deploy the app on. I can't just install .NET 7 on the host server, and expect it to work. Correct?
Q: What about NuGet packages? Do I need to install the corresponding .NET or .NET Core runtimes for every NuGet dependency my app uses?

I would recommend using Docker, or any other container platform like Kubernetes to manage applications like this. It's designed just to avoid situations like this where your application changes to rely on new assets. So you could just basically change the version by just changing a number in your Dockerfile before build and deploy it like any other upgrade. This method is always best practice today. Just swap server application images on your servers for each deployment, no installations.
Alternatively, you could build your application as self-contained (runtime/executable included in your build).
To answer the question, you need the same runtime as your application targers.

how to make project without .Net?

I am making a project in Visual studio in C# and when I tried running the built and published project on my friend's computer it gives an error that a certain version of .Net is not installed. I know that you can make projects in C++ and that doesn't require .Net, but I don't want to learn a new language and I mostly get youtube help from people that code in C#. anyone that knows Visual studio, can you tell me if there is a format I can make the project in? for example, Console application, NUnit test project, etc. thx

You can publish an application with self-contained enabled. This will build an application that includes all the dotnet framework files needed to run the application.
This does make the application bigger, even the most basic dotnet6 console app on my machines is ~10mb and when it's framework dependent it's 160kb
the settings used in the UI:
You can do this in console with:
dotnet publish -r win-x86 -c Release --self-contained true -p:PublishTrimmed=true -p:PublishSingleFile=true
Some good docs on trimming and publishing:
https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/trim-self-contained
https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview
Note on trimmed=true option:
https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/incompatibilities

You need to download the framework that your project is using to be developed in and install it on your friends PC. This is normal and with more advanced software engineering you would build an installer that could install it as part of your applications installation.
For now, check what version of the .NET framework your application is build in. You can do this by going to your Solution Explorer window, right clicking on your solution and selecting properties. It will open a new tab menu on the left of your screen and you want to select the Application. In there you will see a drop down menu labelled "Target framework" which shows what framework your project is using, for example ".NET 5.0"
Once you know which framework your project uses, you can go to https://dotnet.microsoft.com/ to download the installer for that framework on your friends machine. Run the installer and once it has the relevant framework, it should run your application fine.

Additionally to what Istalri Skolir has said, you could also try to optimize for a certain Windows version, by using a preinstalled .NET version.
Here's a list of .NET Frameworks included in specific OS versions.
For example:
Windows 10 May 2019 Update (all editions) includes the .NET Framework
4.8 as an OS component, and it is installed by default
You will need to define the .NET Framework version in the project settings.

Install MSBuild 15 (Microsoft Build tools) without admin rights?

is there any way to install MSBuild 15 on my machine locally without admin rights?
Microsoft's instsaller on https://www.visualstudio.com/downloads/ seems to inevitably ask for admin rights. I've tried looking into the .exe directly with 7zip, but don't think there's much I could manually extract either (looks like the exe is just a web downloader).
Would there by any other way anyone can think of?
--
Why do I need this? I'm developing on a non-admin machine. I could install the NetCore SDK and VSCode withou admin rights, which is great.
For one of my C# projects I'll need MSBuild to compile though (as I'm trying to use WPF/XAML), specifically MSBuild 15 due to the format of my .csproj files.

In case anyone else is trying the same, I managed to do it;
started with Nuget package Microsoft.Build.Runtime, extracted its contents + downloaded all dependent packages into the same folder, plus a few more (several Nuget Build related ones, also available on Nuget).
Had to fiddle a bit with dependencies, environment variables (so my non-admin install of the Net Core SDK would be found) + including build tasks manually etc., but works now. In the end, I was able to use VSCode to compile a WPF application targeting .Net 4.6.1 that references a few other NetStandard 2.0 projects.

Adding .Net framework updates to a setup project

I have a setup project which, as a prerequisite, requires the .Net 4 framework installed locally on the target machine. I specify the install location for prerequisites as "download prerequistes from the same location as my application" resulting in the dotNetFx40_Full_x86_x64.exe being added to the installer (since the target machines we install to are not connect to a network, i.e. standalone).
I'd also like the installer to recognise it needs to install any updates of the .Net 4 framework to the standalone target machine if required. What is the best way to accomplish this?
Thanks in advance.

If you know what updates are required, the simplest way to do it is probably just to create new bootstrapper packages for the standalone updates, and add them as additional prerequisites. There's more info on that here:
http://msdn.microsoft.com/en-us/library/ms165429.aspx

VS2010 build scripts to package DLLs into an MSI & register in the GAC

I have a requirement to package up and release a .NET control library across multiple platforms and have a question on how to automate this deployment (or make as efficient as possible) through build scripts and VS2010 configurations.
The control library is to be released as a Silverlight version (separate builds for SL 3.0, 4.0, 5.0) and WPF version (separate builds for .NET3.5 / .NET4.0). I also need to specify release and trial versions of the same libraries. Trial versions will be differentiated in code with a preprocessor statement TRIAL. Both the trial and full version will be compiled in RELEASE mode.
I'm wondering how to achieve this in the most efficient way possible. My VS2010 solution currently has one project for WPF (.NET 4.0) and one separate project for SL (SL 4.0).
Do I need to create further csproj projects for the missing versions, e.g. .NET 3.5 and SL 3.0 and 5.0?
I wish to create one MSI for all Silverlight DLLs and one MSI for all WPF dlls. Do I need to create further MSIs for the versions compiled as Trial? What about separate MSIs for each version of the .NET or Silverlight framework?
Is it possible to achieve the above deployment packaging using build.targets or build scripts?
Basically if I create manually MSIs for all the above combinations and do a full rebuild that would work, but it is also a laborious process when releasing updates. I am looking for suggestions on how to achieve this with build scripts, build.targets, MSI configurations or a combination of the above.
Finally when redistributing the control libraries, installation should ideally result in registration in the GAC.
Any comments / suggestions welcome.
Best regards,

If you are releasing for different versions of the framework, then you will need different projects. You probably could get away with switching the target framework at runtime, but there are so many variables, by the time you get them all figured out and tested, you could have easily created the additional projects.
I think it would be well worth your money to invest in an Installation tool such as Installshield that has built-in support for the rest of the functionality that you desire.
I believe that you should be able to accomplish all of your needs in a single installshield project using various switches and end user keys (to trigger trial or real installs), but you may potentially consider separating trial and real depending on your licensing scheme.
Update
You can also solve this issue through a pure VS2010 solution, it's just more complicated.
Based on your goals, you will need to have a total of 5 projects and each solution will have 2 configurations, one for release one for trial (where the preprocessor define is set).
You might be able to get away with a single build solution that contains all 5 projects since you can reference the output from each project separately within the VS setup project.
On release, you will have to run the build twice, once for release and once for trial, but you can easily automate this with MSBuild.
What we did to ease the release process burden was create a small database to hold configuration information about the products (locations of solutions, project files, and assemblies) and a small UI application that builds the apps by first changing the version everywhere necessary and then building the installer solution through the visual studio build process.
One very important note that I just remembered as I was typing the above: at one point (it may have been fixed), it was not possible to build Visual Studio 2010 setup projects through MSBuild, which is why we went with building through devenv.com.

For posterities sake I'm recording the solution I came up with thanks to competent_tech's very informative answer.
Solved using an msdos batch file as follows.
Dumped the idea of #If Trial switch. Instead component is licensed by licx file so trial build is the same as release build. This means just one solution for dev work which build outputs are derived from
Created a batch file to rebuild Silverlight and WPF output projects with MSBuild, switching toolsversion to create multiple versions
Copied DLLs over to Nuget style directory structure, e.g. Build/lib/net40, Build/lib/sl4, Build/lib/sl5 etc...
Obfuscate built libs in place
XCopy example projects over to Build/examples/
Use Powershell to edit example projects to reference new obfuscated output.
For reference, please see the following questions and answers on removing/re-adding references and editing project files with powershell