So, I’ve basically create VS Code Projects out of all of my Visual Studio 2022 Projects and it went pretty well (they are all now working as-expected).
A couple things I did run across that I am wondering about and hopefully someone can assist…
I basically just created a directory hierarchy C:\Users\Jeff\Documents\Visual Studio Code\Projects for any VS Code Projects then when I create a Meadow Project I just start there and then use the ‘dotnet new Meadow --output directory’ to create a new project directory and go from there. I then would just copy over the .cs files. I then verify the .csproj has the references needed, connect a meadow board, refresh devices, and try debugging.
But … even though I specify a PackageReference in the .csproj for “Meadow” and I even tried to specify the version (tried “1.3.0” but eventually reverted back to “*”) … and a using Meadow; in the code itself … any reference to any Meadow classes (including App) can’t be found. However, if I add Meadow. in front of App, for example: public class HelloMeadow : Meadow.App … it fixes the problem(s), I can build and run/debug (with the apps working as-expected). And I can even remove the Meadow. reference from App after that, for example: public class HelloMeadow : App … and from that point on, the need to specify Meadow.App instead of just App goes away for that project … anytime I was initially setting up a new project in VS Code, I would have to add the Meadow. temporarily until I build the project, then I can remove it and it all works from that point on. Other than that, things have been pretty smooth when using the VS Code Meadow Extension.
Is there something I am missing while using the extension? I means it’s not a huge deal now that I know how to resolve the problem, but it seems like it’s also something that shouldn’t be needed.
Hi Jeff,
Could you please provide a short snippet or link to a gist showing the before and after code changes? I can’t visualise exactly what you are referring to.
Sure… I just created a new project in Visual Studio Code v1.82.1
As part of that process it creates an app that I guess is used as a starting point. At this point if I go to the MeadowApp.cs file pretty much EVERYTHING that comes from the Meadow Library has a red line under it with an error that will popup indicating that that the namespace can’t be found.
So, the primary class definition starts with this:
public class MeadowApp : App
Both App and F7FeatherV2 are underlined in red (even though at the very top of the .cs module is a using Meadow;) as well as any other references that start with Meadow. (like from Meadow.Devices, Meadow.Foundation, etc.) … primarily because it can’t find Meadow.
If I attempt to run the project a bunch of errors come up during a build that basically indicate the same as the red-underlined problems.
If I do absolutely nothing other than add ‘Meadow.’ in front of the App base class in the derived class specification (basically coding the full reference to the App class … rather than relying on the using Meadow; (which is still present)… for example:
public class MeadowApp : Meadow.App
I then attempt to run … and everything works fine. The App compiles and runs without issues. The red underlines in the .cs file go away.
If I then remove the previously added ‘Meadow.’ from the App base class specification. From this point on, everything works. As if I never added the ‘Meadow.’ to begin with.
I also tried adding Meadow as a PackageReference in the .csproj file but it didn’t help … even tried using a version number instead of keeping “*”.
Hope that explains it better.
Jeff, What version of the VSCode extension do you have installed and also what version of the Meadow.CLI tool installed?
I ask, because it appears you may have an old project template. The new project template, as of our v1.x.x.x release should look similar to this…
using Meadow;
using Meadow.Devices;
using Meadow.Foundation;
using Meadow.Foundation.Leds;
using Meadow.Peripherals.Leds;
using System;
using System.Threading.Tasks;
namespace BlinkyCS
{
// Change F7FeatherV2 to F7FeatherV1 for V1.x boards
public class MeadowApp : App<F7FeatherV2>
{
RgbPwmLed onboardLed;
public override Task Initialize()
{
Resolver.Log.Info("Initialize...");
onboardLed = new RgbPwmLed(
redPwmPin: Device.Pins.OnboardLedRed,
greenPwmPin: Device.Pins.OnboardLedGreen,
bluePwmPin: Device.Pins.OnboardLedBlue,
CommonType.CommonAnode);
return base.Initialize();
}
public override Task Run()
{
Resolver.Log.Info("Run...");
return CycleColors(TimeSpan.FromMilliseconds(1000));
}
async Task CycleColors(TimeSpan duration)
{
Resolver.Log.Info("Cycle colors...");
while (true)
{
await ShowColorPulse(Color.Blue, duration);
await ShowColorPulse(Color.Cyan, duration);
await ShowColorPulse(Color.Green, duration);
await ShowColorPulse(Color.GreenYellow, duration);
await ShowColorPulse(Color.Yellow, duration);
await ShowColorPulse(Color.Orange, duration);
await ShowColorPulse(Color.OrangeRed, duration);
await ShowColorPulse(Color.Red, duration);
await ShowColorPulse(Color.MediumVioletRed, duration);
await ShowColorPulse(Color.Purple, duration);
await ShowColorPulse(Color.Magenta, duration);
await ShowColorPulse(Color.Pink, duration);
}
}
async Task ShowColorPulse(Color color, TimeSpan duration)
{
await onboardLed.StartPulse(color, duration / 2);
await Task.Delay(duration);
}
}
}
The latest VSCode Tools For Meadow should be v1.3.0
Could also run the following command so you have the latest Meadow.CLI installed:
dotnet tool update Wildernesslabs.Meadow.CLI --global
which should also be v1.3.0
Dominique,.
Yep, my TestApp (that I created just before the last response looks identical). I wanted to make sure that I was seeing the problem before I responded.
Meadow.CLI is v1.3.0 (I ran the suggested command, it indicated I already had v1.3.0).
And … the VSCode Tools for Meadow is also v1.3.0.
Everything is working fine when I create a new Meadow Project in Visual Studio 2022 (Enterprise … not that it should matter which version of Visual Studio 2022 I use, I don’t think) using the Meadow Application (Wilderness Labs) template … which creates a project very similar to what I see in VSCode, and it compiles without issues. I think that should indicate that my ‘Meadow’ install is correct. It’s just under VSCode that I see the problem. It’s not terrible to recover from it, but it is odd.
The only other VSCode extensions I have installed are .NET Runtime Install Tool, C/C++, C#, Serial Monitor and WSL (all from Microsoft), vscode-icons (from VSCode Icons Team) and VSCode Tools for Meadow (from Wilderness Labs).
The top of your app class should look like this, if you have the latest templates installed…
and when you posted your class example you said it was…
public class MeadowApp : Meadow.App
Be sure it is the former, with the latest versions you have installed.
Because the important distinction between what I had to do to resolve the problem had nothing to do with which board I was using (I have a V1 and V2 board) … I was attempting to show the change I was making to resolve the problem nothing more. So, I only showed up to the App and Meadow.App (which fixes the problem) … anything after that wasn’t important … and I don’t believe there was ever a version where there wasn’t something after App … i.e. App<F7Micro, T> or similar and therefore any earlier Meadow Tool wouldn’t be generating it that way). Sorry for the confusion.
