INotifyPropertyChanged.PropertyChanged implemented and not implemented; Visual Studio build error

Question

I see a strange build error. Sometimes after entering some code, we get the following build error.

Class 'clsX' must implement 'Event PropertyChanged(sender As Object, e As PropertyChangedEventArgs)' for interface System.ComponentModel.INotifyPropertyChanged'. 

AND

 'PropertyChanged' cannot implement 'PropertyChanged' because there is no matching event on interface 'System.ComponentModel.INotifyPropertyChanged'. 

These errors should never be combined! Usually we can simply ignore the exception and build the solution, but quite often this error stops our assembly. (this happens very often using Edit and Continue, which is annoying)

We use Vb.net and C # in one big solution.

Removing the PropertyChanged event and re-typing the same code! sometimes corrects it.

Question:

Has anyone else seen this problem and has some recommendations on how to prevent it?

We use a code generator that causes this error, but just editing some files manually also raises this exception. This error occurs on multiple computers using various settings.

Answer 1

Someone had the exact same question discussed here . There seems to be a problem with this assembly building the old version of the binary. I will try to do the following:

• Check all assembly references where possible, within the scope of the Visual Studio solution, use project references.
• Disable assembly parallelization in case there is some strange problem of blocking files with parallel project assemblies. Go to "Tools" - "Options", "Projects and Solutions" → "Build and Run", and then set the "maximum number of parallel-mounted prefabricated projects" to 1. Not the best solution, but it can help reduce the problem.
• Disable the Hosting Process if it blocks some file, as a result of which the assembly will not be restored correctly. For a C # project, go to the Project Properties tab, the Debug tab, and uncheck the Enable Visual Studio Hosting Process box. For a VB.NET project, you will need to unload the project, edit the project file and add <UseVSHostingProcess> false </UseVSHostingProcess> in the PropertyGroup of each configuration. Again, not the best solution, but you probably won't notice the difference.
• Finally, try to do Clean + Build to try to solve the problem when it happens (I know that this is not a fix, but it is easy enough to do), also Rebuild may be slightly different from Clean + Build , so try the latter if the first one works.

Answer 2

As I can not comment due to the lack of relevant points. But I would like to share one of my impressions:

On the aspx.cs page, I worked, was used to compile, and for some time gave a mysterious error to a variable not defined or a function not defined or once a variable, or a function given twice. I changed, perhaps, each variable and the name of the function, but the effect did not appear, but after entering a simple space or a new line anywhere in the file used to solve the compilation error. At one time, I tried to save the file (in a different encoding, as I was used to experimenting), and found that the file did not save the correct encoding (i.e. ansi encoding ), because the file had unicode), I deleted the Unicode character, and this the compilation error no longer bothered me.

This Unicode character issue might be (rather than hard and fast) there so you can check it out.

Answer 3

Nuke and restore using source control (TFS instructions here):

• Make sure you have everything checked in
• Exit Visual Studio
• Rename the project directory to .Bak (effectively deleting it)
• Re-open Visual Studio and in version control:
  
  • Get a specific version
  • check "Overwrite ... not verified" and "Overwrite ... even if the local version matches"
• Reopen the project

Another problem: make sure that some source files are not newer than the current date (or the date is set). This often happens in applications where you make logic that requires certain things that will happen differently on certain dates. You change your watch to test it, make corrections to the source using the specified date, set the date back and alt, rebuild will not rebuild this file.

You say "typing it again" - can you try just saving? 40 years after MULTIX, the .net assembly still decides what has changed by checking the file's timestamp.

Good luck

Answer 4

When you get an error, is it always on the C # side causing the VB call, or vice versa, or is it working in both directions?

If the answer is one of the first two situations, try creating a “called” project in the solution before creating a “calling” project to see if it stops the situation.

Also, just in case, when you can think of something, can this error occur when a VB file or a C # file changes or is there no correlation?

Oh, and sorry that this seems like an answer instead of a comment, I can't leave comments yet (need 50 rep).