I have a console application. VS2022 is not listing any .NET Frameworks except 6.0 although I have others installed on the machine.
When using a Windows Application (not console application), I get to select the framework I want such as 4.7.2 for example.
I tried to re-install 4.7.2, but the installer was clever and figured that I already have it.
Confusing aspects in the project configuration from within the solution:
When no OS is selected, the programmer gets no warnings.
When OS is selected to be Windows, Not all the available .NET frameworks appear.
My question is how to "make/force" VS2022 to allow me to select the desired framework?
Thanks.
Related
I'm using Visual Studio 2019 and just created a new .NET Core 3.1 web api project.
I noticed, that an option "use remote machine" is missing from the debug tab of project's properties.
However, when I open my old project, created in older versions of VS using .NET Core 2 (and then migrated to 3.1) - the option is present.
I've only recently started needing it and this inconsistency is strange to me.
This ticket on Microsoft website https://developercommunity.visualstudio.com/t/use-remote-machine-option-in-debug-settings-is-not/757921 suggests that it should be fixed in the latest version of VS, but I use the latest version and the problem still remains.
I figured it out, was my mistake. I needed to explicitly set launch option to executable. Then it becomes available. I should close the question.
I have a simple Solution in Visual Studio 2019 Community edition with a C# Class Library (.NET 5.0), a Windows Forms application (.NET 5.0), and a command line interface (also .NET 5.0). The Forms and CLI both reference the library. Everything works great on Windows at the moment. I would like to create Mac versions of the applications. I have some general awareness of Mono and that everything I have done so far should work fine in Mono and cross platform (eventually, some of this might also be used in a Unity app, but that's not a priority at the moment).
What is the quickest and simplest way to take my VS 2019 solution and build the Windows Forms and CLI for Mac? Ideally I'd like to do this from my Windows environment.
I have read a number of posts and done some googling, and started to go down a few rabbit holes, only to find out they are outdated etc., so I thought it best to ask here and get a fresh response.
I will try to explain this as clear as I can
I want to fully understand how MSBuild multitargeting works.
I have read several articles from Microsoft and I think I understand the basic but I want to be sure I am not missing anything.
According to Microsoft:
By using Visual Studio, you can compile an application to run on any one of several versions of the .NET Framework. For example, you can compile an application to run on the .NET Framework version 2.0, and compile the same application to run on the .NET Framework version 4. The ability to compile to more than one framework is named multitargeting.
Visual Studio runs under the most current version of the .NET Framework that is installed on the development computer.
http://msdn.microsoft.com/en-us/library/ee395432.aspx
So do this mean that Visual Studio always calls MSBuild from the latest framework installed? assuming Visual Studio 2010 is installed, it will always call: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe when building any project targettting any .Net Framework version right???
If yes, then the ability to target old .Net Framewrok versions is based on the ToolsVersion and/or TargetFrameworkVersion properties right???
If yes again, it would mean that just installing the latest framework (and also the older frameworks but not installing visual studio) in my Continuous Integration box, I could point to build always any solution to: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe and just specify the ToolsVersion argument (if required, since each project can have its own target version specified in the TargetFrameworkVersion which it would cause to target an older .Net Framework version).
Following this I think my CI box would be building like Visual Studio does. Am I right? What am I missing? Is there a way to be completely sure?
I did a quick test, and I think it works :p the projects are being built according to the .Net Framework specified but like I said I want to be sure I am not missing anything.
Any thoughts?
BTW:
The simple reason to want to do that is because I have several custom MSBuild scripts that are reusable accross projects, but some of the functionality in these scripts require MSBuild 4.0 and also I have several MSBuild tasks built on top of the framework 4.0 so if I have for example a solution targetting the Framework 2.0 and I try to build it using: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\MsBuild.exe I get MSBuild errors trying to load my custom targets
Yes, you've got it mostly correct. Calling MSBuild from the 4.0 directory will do the correct thing against previous versions. They only thing I wanted to add was that 3.5 must be on the box to actually build projects targeting 2.0, 3.0 and 3.5.
This page here: http://msdn.microsoft.com/en-us/library/bb822049.aspx calls out the what versions Windows comes with what version of the framework pre-installed.
I am developing a Windows CE application which uses some libraries provided by other parts of our company.
When I deploy my application on "My Computer" (.NET compact application running on standard PC), everything works, but when I deploy to the device, the application hangs when trying to use methods from the library. The system also hangs. My Visual Studio 2008 sometime hangs, but sometime throws an exception "TypeLoadException: Could not load type from assembly Culture=neutral, PublicKeyToken=nu".
I couldn't include .NET Compact framework 3.5 because the image wouldn't compile, so I am using version 2.0. I use Visual Studio 2008 with deploy .NET framework option.
Most probably the problem is with version of the library you are using. Please cross check it.
Hope this link will help you.
I'm a bit confused.
First of all, what are the libraries "provided by other parts of [y]our company" build against? Are they Compact Framework assemblies (they must be)? What version of the Framework were they build against? Reflector can tell you this if you don't know.
Second, why can't you compile it with 3.5? What sort of errors are you seeing? The code should be 100% forward compatible, so if it won't build, there's a red flag going up.
Lastly, what version of the CF is installed on the target hardware? FOr example, are you trying to push a CF 2.0 app to a device with CF 3.5 already installed? If so, do you have an app.config file that provides the framework compatibility options so it knows it can run your assembly?
The problem was that libraries were compiled with for 3.5 target framework, and the application which uses them form 2.0 framework. In that case, 3.5 framework wasn't depoloyed and application would stop working as soon as call to the library methods was made.
I am using VS2010 ultimate Beta2 and under Visual C# -> Workflow -> I don't see the Sequential workflow console application or state machine console application
Could someone please advise why these are missing in VS2010. I am able to see them on VS2008 ->Workflow.
Thank you
In VS2010 Pro RC1 the sequential workflow console app and state machine workflow console application are only available if you choose .Net Framework 3.5 in the combobox above the project types.
But why worry about beta 2, now that RC1 is out?
I would think that if this is a true and serious error, a bug report is probably better than a SO question.
As Guge says this is by design (It's the same in Beta/RC or RTM). In Visual Studio 2010 you have 2 different versions of Windows Workflow. The new one (4.0) uses a new runtime under the hood and has a WPF look and feel. The designer/activities are different.
The old one (3.5) -also called Legacy- can only be created in Visual Studio 2010 if you change the target framework to 3.5 or 3.0. After you do that you will have the option of State Machine/Sequential WF Console App.
Note however that after you have created the 3.5 workflow you can retarget to 4.0. This will keep the same designer/runtime but it will be running under the 4.0 Framework. Everything will work as expected.
If you try to upgrade and existing VS2008 project you will get the option of doing this.