You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you meant a list of what the importer does? All it does is create a new project, and copy your existing source code into it. It doesn't modify anything existing in your project, or try to be smart at all about anything you're doing in gradle.
@ThadHouse ok, then I won't worry about it. I dimly remember cribbing from a template project the last time i did this import, in 2025.
@sciencewhiz it starts, and then "failed to determine robot class" and then "failed to update". it seems to have copied the "src" directory but that's all it does.
the project is team100/all26/lib, but I really don't want you to worry about it.
It looks like there's a few different things going on.
It fails to determine robot class because your build.gradle defines the ROBOT_MAIN_CLASS as "frc.robot.Main", but that doesn't exist, and in fact you don't have a main that I can find. Pre-2027 importers just copied the main.java file, but now that file is generated and the old one is parsed to find what the robot class is. I'm not quite sure how your project actually worked before, but that's definitely a non-standard change to project structure.
However, it should have prompted you to enter the robot class, and it doesn't. Looking back through several years of code, I don't think that's ever worked, so that's a bug in the VS Code extension.
Lastly, your projectYear is still 2026beta. That means you either didn't install a 2026 release, and only manually updated the gradle version, or you did install a 2026 release, and ignored importing. The main side effect that I can think of is that the vendor dependency manager would only show beta compatible vendordeps, and not the vendors released versions. If you don't use that feature, you might have been ok. Although we've now improved checking in 2027, and you might have more problems if everything isn't matching.
Thanks for looking. it's a weird project, I guess. it's only ever used as a "library" by other projects that do have "main" files, though I run the lib tests independently in the CI.
Anyway, the good news is the initial manual fixing went fine, all my tests pass (about 900 tests), with only a few bits removed for now.
Hello, my team is having the same issue as well on our robot code, where the importer says "Failed to determine robot class. Enter it manually?," and clicking yes pops up the same VS code issue that @truher is experiencing. I tried this on our team's 2025 and 2026 repo and both didn't work. team4099/Offseason-2025 and team4099/Rebuilt-2026. We're trying to update to alpha-5
We might just wait for alpha-7 since it'll require a reimport anyways. cc @SirBeans
I tried this on our team's 2025 and 2026 repo and both didn't work. team4099/Offseason-2025 and team4099/Rebuilt-2026. We're trying to update to alpha-5
We might just wait for alpha-7 since it'll require a reimport anyways. cc @SirBeans
Given that your code is Kotlin, I don't thing I'd expect that the importer would work.
Yeah true, which is unfortunate because the importer has worked for us in years prior. But given the mention of how it generates the main.java file now, I see how that may(?) be part of the issue
Before this season I never really thought about what the importer was for, or what it did. If all it does is makes a new project and copies the code into it, maybe it would be better to have transparent, obvious importing instructions rather than an opaque and error-prone import automation?
It also has some infrastructure to do namespace and classname changes.
If we did document it, all we would say is to create a new project, copy your classes over, and then fix all the namespace issues. Since we have 0 clue how teams modify their projects, actually creating how to change projects is not worth the effort. Because the teams that have issues with the importer are always teams that have changed things about the build.
TBH the main issue for us has not been the importer at all, it has been the import complainer, whatever it is that decides our projects are "in need of importing" in some way, and occasionally the students will just click "OK" when it solicits the import, and then the car is in the ditch. It's not true, the projects work fine, I have no idea why the complainer is complaining, and I don't want anyone to try to figure it out. I know I can tell it to shut up, but it comes up for every student the first time they open any one of our (quite a few) projects.
All that’s drives that is the wpilibYear in the preferences json. If you update that when you do your updates, that solves that issue. That also makes the vendor dep page look at the right year.
Heh, sure. You see the point, though, right? Like, this whole thing is just a kind of magic that works great until it doesn't, and then it's just broken unless I happen to hit up Thad on a Wednesday night.
The reason why those are the 2 methods is essentially every year all the files we provide change. So anything we document would be "copy this archive of files into your project, and manually change these things because some things need to know the information in your old project". It's just so much easier to tell people create a new project and copy your code in, or use the importer. It does exactly that same thing, just automatically.
The reason we can't provide a list of what to change is for non standard projects, the list of what to change is completely unknown, because who knows what the user has changed. The only people that have trouble with this workflow are the people who modify their projects, which are the exact people we can't document for because we don't know what they've changed.
The solution we want people to go for is to take our projects and apply their own patches on top. Not figure out what we've changed and apply those on to their already modified projects. That becomes impossible to maintain.
The Import incorrectly tries to co-op our classes. We have some similarly named classes (c++) to wpi class names and it changes them to have wpi::. For instance, we have had a class which doesn't have anything to do with wpi::Logger but it co-ops it even though there isn't the correct include. We don't use namespaces in our code much (most namespaces are coming from wpi and vendor deps), but what we see is even without the previous include it tries to make it a wpi item. It would have been easier if you would have done something like using wpi::Logger at the top of the file, instead we have to go to all of the instances and fix them.
The Import incorrectly tries to co-op our classes. We have some similarly named classes (c++) to wpi class names and it changes them to have wpi::. For instance, we have had a class which doesn't have anything to do with wpi::Logger but it co-ops it even though there isn't the correct include. We don't use namespaces in our code much (most namespaces are coming from wpi and vendor deps), but what we see is even without the previous include it tries to make it a wpi item.
Can you be more specific about the classes you're having trouble with? Most (but not all) things the importer does are prefixed by the namespace. It's unclear if Logger is the only one, sounds like you might be referencing more.
I’m working through, so I’ll add more details later.
The biggest one was we have a class named Logger without any namespace. It is used in a lot of files. We include our logger.h. This class is a singleton used by many classes. So the callers have something like Logger::GetLogger()->PutString(…); It is getting replaced with woo::Logger::GetLogger()->PutString(….);
Activity
ThadHouse commentedon Jul 12, 2026
We don't have a direct list, you'll have to compare what a fresh project looks like.
Note alpha 7 will also be heavily changing how gradlerio is hooked into, and also require a reimport and update.
ThadHouse commentedon Jul 12, 2026
If you meant a list of what the importer does? All it does is create a new project, and copy your existing source code into it. It doesn't modify anything existing in your project, or try to be smart at all about anything you're doing in gradle.
sciencewhiz commentedon Jul 12, 2026
Can you explain what you mean by it fails? Does it not start? Does it give an error message? Does it create a non-working project?
Can you link to your project you're trying to import?
truher commentedon Jul 12, 2026
@ThadHouse ok, then I won't worry about it. I dimly remember cribbing from a template project the last time i did this import, in 2025.
@sciencewhiz it starts, and then "failed to determine robot class" and then "failed to update". it seems to have copied the "src" directory but that's all it does.
the project is team100/all26/lib, but I really don't want you to worry about it.
sciencewhiz commentedon Jul 13, 2026
It looks like there's a few different things going on.
It fails to determine robot class because your build.gradle defines the ROBOT_MAIN_CLASS as "frc.robot.Main", but that doesn't exist, and in fact you don't have a main that I can find. Pre-2027 importers just copied the main.java file, but now that file is generated and the old one is parsed to find what the robot class is. I'm not quite sure how your project actually worked before, but that's definitely a non-standard change to project structure.
However, it should have prompted you to enter the robot class, and it doesn't. Looking back through several years of code, I don't think that's ever worked, so that's a bug in the VS Code extension.
Lastly, your projectYear is still 2026beta. That means you either didn't install a 2026 release, and only manually updated the gradle version, or you did install a 2026 release, and ignored importing. The main side effect that I can think of is that the vendor dependency manager would only show beta compatible vendordeps, and not the vendors released versions. If you don't use that feature, you might have been ok. Although we've now improved checking in 2027, and you might have more problems if everything isn't matching.
truher commentedon Jul 13, 2026
Thanks for looking. it's a weird project, I guess. it's only ever used as a "library" by other projects that do have "main" files, though I run the lib tests independently in the CI.
Anyway, the good news is the initial manual fixing went fine, all my tests pass (about 900 tests), with only a few bits removed for now.
00magikarp commentedon Aug 12, 2026
Hello, my team is having the same issue as well on our robot code, where the importer says "Failed to determine robot class. Enter it manually?," and clicking yes pops up the same VS code issue that @truher is experiencing. I tried this on our team's 2025 and 2026 repo and both didn't work. team4099/Offseason-2025 and team4099/Rebuilt-2026. We're trying to update to alpha-5
We might just wait for alpha-7 since it'll require a reimport anyways. cc @SirBeans
sciencewhiz commentedon Aug 13, 2026
Given that your code is Kotlin, I don't thing I'd expect that the importer would work.
00magikarp commentedon Aug 13, 2026
Yeah true, which is unfortunate because the importer has worked for us in years prior. But given the mention of how it generates the main.java file now, I see how that may(?) be part of the issue
truher commentedon Aug 13, 2026
Before this season I never really thought about what the importer was for, or what it did. If all it does is makes a new project and copies the code into it, maybe it would be better to have transparent, obvious importing instructions rather than an opaque and error-prone import automation?
ThadHouse commentedon Aug 13, 2026
It also has some infrastructure to do namespace and classname changes.
If we did document it, all we would say is to create a new project, copy your classes over, and then fix all the namespace issues. Since we have 0 clue how teams modify their projects, actually creating how to change projects is not worth the effort. Because the teams that have issues with the importer are always teams that have changed things about the build.
00magikarp commentedon Aug 13, 2026
Is there a way to get a "clean" version of the build.gradle, so that we can make the manual changes ourselves
ThadHouse commentedon Aug 13, 2026
Create a new project, and then take everything else from there. Or copy your code into that new project.
truher commentedon Aug 13, 2026
TBH the main issue for us has not been the importer at all, it has been the import complainer, whatever it is that decides our projects are "in need of importing" in some way, and occasionally the students will just click "OK" when it solicits the import, and then the car is in the ditch. It's not true, the projects work fine, I have no idea why the complainer is complaining, and I don't want anyone to try to figure it out. I know I can tell it to shut up, but it comes up for every student the first time they open any one of our (quite a few) projects.
ThadHouse commentedon Aug 13, 2026
All that’s drives that is the wpilibYear in the preferences json. If you update that when you do your updates, that solves that issue. That also makes the vendor dep page look at the right year.
truher commentedon Aug 13, 2026
Heh, sure. You see the point, though, right? Like, this whole thing is just a kind of magic that works great until it doesn't, and then it's just broken unless I happen to hit up Thad on a Wednesday night.
ThadHouse commentedon Aug 13, 2026
That’s why we’ve always said either use the importer, or create a new project and copy your code in.
If we provide supported ways and they’re not used, I wouldn’t expect things to work.
ThadHouse commentedon Aug 13, 2026
The reason why those are the 2 methods is essentially every year all the files we provide change. So anything we document would be "copy this archive of files into your project, and manually change these things because some things need to know the information in your old project". It's just so much easier to tell people create a new project and copy your code in, or use the importer. It does exactly that same thing, just automatically.
The reason we can't provide a list of what to change is for non standard projects, the list of what to change is completely unknown, because who knows what the user has changed. The only people that have trouble with this workflow are the people who modify their projects, which are the exact people we can't document for because we don't know what they've changed.
The solution we want people to go for is to take our projects and apply their own patches on top. Not figure out what we've changed and apply those on to their already modified projects. That becomes impossible to maintain.
sciencewhiz commentedon Sep 6, 2026
WPILib Alpha 7 no longer uses the ROBOT_MAIN_CLASS for importing, so I'd expect your code to import again.
witcpalek commentedon Sep 18, 2026
The Import incorrectly tries to co-op our classes. We have some similarly named classes (c++) to wpi class names and it changes them to have wpi::. For instance, we have had a class which doesn't have anything to do with wpi::Logger but it co-ops it even though there isn't the correct include. We don't use namespaces in our code much (most namespaces are coming from wpi and vendor deps), but what we see is even without the previous include it tries to make it a wpi item. It would have been easier if you would have done something like using wpi::Logger at the top of the file, instead we have to go to all of the instances and fix them.
sciencewhiz commentedon Sep 18, 2026
Can you be more specific about the classes you're having trouble with? Most (but not all) things the importer does are prefixed by the namespace. It's unclear if Logger is the only one, sounds like you might be referencing more.
witcpalek commentedon Sep 19, 2026
I’m working through, so I’ll add more details later.
The biggest one was we have a class named Logger without any namespace. It is used in a lot of files. We include our logger.h. This class is a singleton used by many classes. So the callers have something like Logger::GetLogger()->PutString(…); It is getting replaced with woo::Logger::GetLogger()->PutString(….);
witcpalek commentedon Oct 21, 2026
Another example is:
PUGI__FN bool starts_with(const char_t *string, const char_t *pattern)
got changed to
PUGI__FN bool wpi::util::starts_with(const char_t *string, const char_t *pattern)
There are no wpi includes in the file (it is actually a third party library that we compile in.
witcpalek commentedon Oct 21, 2026
Variables got changed to wpi items:
So this:
got changed to this:
Obviously chassisSpeeds shouldn't have changed because it is a variable name not a data type.