I create an Island project in VS 2019 in order to target an Raspberry PI 3. Works debugging included. (We would have to talk about an unresponsive VS later, but that’s not the point. Restarting helps.
Which brings me to the point that really hurts.
When I close the project and try to open it once again VS does not load the project, rather a dialog shows up which gives me three options
a) Changing the Target to 4.6.1 and revert it to to Version 4.0 later
b) …
c) … Don’t load the project.
No matter what I do the project remains unloaded.
I tried to add the TargetFramework to the project file but that didn’t help at all. Since I had no real idea what I’m doing, not big surprise at all.
I’d guess, but I have no idea why, VS simply does have no information about a TargetFramework. Wondering why it would need such a thing. Maybe a specialty of the template that comes into play in the last line of the project file?
Elements 10.0.0.2513 in VS 2019 on Win 8.1.
Any idea? Help is appreciated.
(*No need to hurry in general. But I tried pretty much the same before in Fire which
came with a little older version of Elements and it worked more stable (but I cannot upgrade that machine anymore). So I was happy that I got a connection under VS2019 using this newer version of Elements. I had the impression that debugging aarch64 worked too on the Mac but no chance on the Windows Machine with VS just armv6. That’s not the problem at the moment. Digging deeper into such matters requires projects files that can be loaded twice or more often. Otherwise I have to create a new project every day if anything else worked smooth *)
Tested. I created a new Island project (no matter if Win or Linux) and yes the problem persists in general. I doubt that it is a problem still.
(* I personally use Water and Water doesn’t allow me to remote debug against Linux (Run & co buttons stay disables). That’s why I used VS. In general I was deeply impressed before, when it came to debugging especially. *)
What needs to be done in order to make the problem described above go away is to set the Target Framework in the configuration to in my case .NETFramework 4.8. On time out of 15 projects it did not, but let’s ignore that (maybe I made a mistake, worked again afterwards).
I could imagine that other people like me have .NET Core installed and in that case, maybe the problem does not show up. I just found out that I have a .net Core SDK 3.1.300 installed. (just 168 KB must be the baby edition).
Another problem arose. I changed the platform to arm in the configuration and the compiler tells me Unsupported architecture (‘arm’) fro Ubuntu 2.19.
That happens for any other architecture (offered by VS) too. I think because the Architectures offered (arm, X86, X64) do not correspond with X86_64 presented in the Project Properties (Configuration dialog).
Can I somehow workaround this?
(* All in all, that’s the good news, the whole project system is a lot lot faster than before and a lot more responsive. Congratulations. *)
I forgot to mention before.
Is there a certain kind of ‘Show Advanced configuration?’ as in Fire. I cannot set target an like Ubuntu or Ubuntu 2.19 Anymore. I also don’t see the settings you have in your last screenshots starting with X86_64, aarch64 in VS 2019 (maybe today’s update changed that but I started to use VS short before. So I cannot really tell…) in the Piclist or Dropdown (when a value for a cell in the grid is selected).
Reply to answers. Thank you.
a) Video. The same works for me now if I select the .Framework manually.
I think VS requires a valid ‘Target Framework’ in order to load a project. I’ll have a look at this. But that doesn’t matter that much, since selecting the Framework helps. But I will have a look. (I didn’t install VS 2019 with default options and explicitly removed .NET Core from install). I doubt there is a second one who did. I guess that was my ‘fault’.
b) I don’t have the Subsystem for Linux installed locally. Win 8.1 and I doubt I will install it even on Win 10. This doesn’t help me with ARM devices anyway.
c) As mentioned at the beginning of this reply, no problem anymore.
d) I don’t see all these options. I have walked through the configuration Matrix once again. After the project is created i see the string ‘x86_64’ but once I drop down and change the architecture I see (Any CPU, x86, x64, ia64, arm) which reminds me of .net. When I look at the screenshot you attached I see Architectures for Mac (Match Device) before the binary name.
(*btw. Clear Settings one the SubMode under Import is set and VS crashes (stops to respond) when settings that are not relevant for a specific configuration are selected. That not an issue. But when I was looking where to set ‘Ubuntu’ or ‘Ubuntu 2.19’ I simply had a look into almost every setting and Piclist. That’s why I came across this. That’s not a problem. *)
VS usually shows all the options offered in the configuration matrix, but I don’t know in how far code is reused among the various IDE integrations.
Don’t get me wrong. From my side there is no urgency involved, because as long as I can compile with either Fire or Water and debug in ‘printf’ style under Linux I see no reason that keeps me from going on Linux.
I was deeply im pressed by the stability of the debugger in general and the various insights I get that way.
It’s easier to pin certain error messages down to a specific IDE, ‘Elements’ in general and configuration issues maybe concerning gdbserver and such things, those things I can influence, monitor or trace.
In general Fire is a good option when it comes to Linux targets. Just let me know if reinstalling Visual Studio using the default installation settings helps. I’ll keep the configuration the way it is for the moment until you advise to not do any longer.
ARM computers are preferred at the moment since they are already fast enough, small in size and a wonderful replacement for removable hard drives (‘small’ databases for example …), test environments for network configurations including some ‘special’ devices from China with ‘tons’ of network connectors, passive cooling and silent, more or less ‘lab’.
I work on ARM devices plus Linux already the same way I worked on a Mac or Windows PC in the past too.
Anything else seems to work satisfactory for the moment anyway. I will not go via VS if I write a (small) iOS app, but for command line programs having an option to go with water too makes my live in the home-office (that’s the one I have at the moment) a lot easier.
Thank you very much. Great. That goes far beyond what I expected. I just returned, so I will give it a try immediately and let you know. I personally don’t need more than plain Water.
I guess that was my ‘fault’.