Community.Toolkit.MVVM Error on [ObservableProperty]: The name 'x' does not exist in current context
Just getting started with CommunityToolkit. I'm developing a VS Extension (essentially a WPF app).
My MainViewModel contains:
The source generation is working properly, because I can access
Authenticated
(see image)
However, when I build the project, I get
ViewModels\MainViewModel.cs(51,13,51,26): error CS0103: The name 'Authenticated' does not exist in the current context
and the build fails. My MainViewModel is instantiated through MainView.xaml:
Weird thing is it did work for a while, but something happened and it's gone mental with my xaml showing as full of errors (despite it previously working and being unchanged).
EDIT: Isolated the cause:
When I include the below, it breaks the build. Omit it and it works again:
Eccluding all the FlowException code, but retainng basic RelayCommand also breaks the build:
Howevere, the below builds:
Code here: https://github.com/stigzler/VisGit/tree/1-setup-base-extension-environment
Any ideas?GitHub
GitHub - stigzler/VisGit at 1-setup-base-extension-environment
A Visual Studio Extension allowing the project management of your Git Repos from Visual Studio - GitHub - stigzler/VisGit at 1-setup-base-extension-environment
13 Replies
@ref *&Sergio
NArrowed it down a little and updated OP
To add (as ran out of words in OP):
If I set
_exceptionMessageText
to a value, it displays correcly in the xmal binding (Text="{Binding ExceptionMessageText}"
). However, if I try to assign ExceptionMessageText a value in the ViewModel itself, I get the does not exist in the current context
error again for this property.Code is also being generated:
🤷
Anyone? Still stuck on this. The hype was great, but sadly its implementation isn't a great expreince so far!
Hey! Sorry, I missed this yesterday. Can you summarize the issue? 🙂
Hey - no probs and thanks for checking in. It may be clearer on the StackOverflow post here: https://stackoverflow.com/questions/78619310/build-errors-when-using-communitytoolkit-mvvm-with-visual-studio-extensions/78621701#78621701
I also rose an issue against the repo here: https://github.com/CommunityToolkit/dotnet/issues/889
GitHub
Build errors when using CommunityToolkit.MVVM with Visual Studio ex...
Describe the bug I've asked around on SO and discord, but getting no joy. Forgive me if this is my misunderstanding. My SO post: I'm getting build errors despite the SourceGenerator apparen...
Stack Overflow
Build errors when using CommunityToolkit.MVVM with Visual Studio ex...
I'm getting build errors despite the SourceGenerator apparently working correctly. Example code:
namespace VisGit.ViewModels
{
public partial class MainViewModel: ObservableObject
{
...
...
@ref *&Sergio - hey sorry to ping you on this - but do you have any ideas? I've scoured the internet and am totally stuck on this issue. Really want to use this library, but impossible to do so atm. A basic starting point would be: can you use this with Framework 4.8 and can you use it in VS extension development or is there something about the dev environment that breaks mvvm toolkit?
Are you using
packages.config
by any chance?
I suspect it's some tooling issue in that project type. I would recommend moving all those viewmodels etc. to a separate project (eg. NS2.0, or NETFX4.8 as well), and reference that in your final VS extension project. That should work
(or at least, worth a shot)
This did fix a similar issue on WPFhey - sorry missed this. Is packages.config linked with nuget source mapping? I did turn this on via VS options, but can't find any packages.config file in my solution folder.
Just disabled package source mapping and re-installed the lib. Still bugs out on
[Observable Property]
- will refactor to separate lib tomorrow. Just for clarity - is this a known difficulty with Ext Dev in VS?
(weird thing is [Relay Command]
works fine)
@ref *&Sergio I'm really sad that you or any members of your team aren't helping with this issue. It really is very short sighted of MS not to support extension developers. Poor show. 👎👎👎 - the dicky performance of your code has brought my dev to a standstill.Well you're certainly not going to attract people willing to help with that attitude. I told you I have been busy this week and apologized. I offered some help and told you to put that code in a separate project, which should fix the issue. And yes, the issue is caused by VS and that project type, it's not a bug in the MVVM Toolkit. So you're not even getting mad at the right person, let alone you shouldn't be getting mad at anyone
With respect, Sergio, it's the interface between the toolkit and VS environment/stack, which is a core aim of the toolkit - thus it is related to the toolkit code. You also work for MS, so more broadly speaking the answer comes somewhere between you or your colleagues at VS. I do really respect what you've created here, but am so frustrated that a team as big and as well resourced as MS don't help their users over what should be core functionality. I also do think it's really short sighted of MS as VS extension developers essentially attract/maintain users and thus revenue. I updated the Issue on GItHub with a pointer to the SO post which has the specific repo branch demonstrating the problem. I think the biggest issue that caused this response from me was just the total lack of any communication on the GH issue. Great code is awesome, but communication and respect for persons is fundamental. I'm sorry if this came across as personal - that wasn't my intention and maybe I was a bit cross, but it was more your role as a MS employee. I have split it out into its own project (which has brought its own problems) so will just battle on with that. I also know your to-do list is likely very long (?) but maybe consider having a look at the toolkit <> vsix interface at some stage (or your colleagues)?
I get that you're frustrated, but there's really nothing that Sergio or the people who work on the CommunityToolkit can do about it. They're just a source generator, nothing more; some other part of the ecosystem is misbehaving, likely one of the temp projects that either wpf or the vsix tooling creates is not running the source generator when it should. What could be helpful to track down the right people to look at the issue is getting a binlog of the build so that you can determine what step is actually failing, and what arguments are actually being passed to the compiler when it fails
thanks for the constructive point, fred