[tlhIn`toq]

Maybe I just shouldn't code on the weekends.
I have had no troubles in the past of making control libraries and using them in applications: Until today. I'm about to nuke my Visual Studio and re-install it; its that weird. I'm hoping someone else has seen this or can point out what the frak I'm doing wrong.

The VS solution is fairly simple: A control library project and a WPF application to test the controls I'm making.
Reference to the library has been added to the Application project.

• So next I compile and my ToolBoxd shows the controls from CwpfLib. Great.
  
• I open the MainWindow from the test application.
  
• I drag a TextBoxWithEllipse to the window. Appears as if no problem: It shows up, appropriate namespace shortcut is created in my XAML automatically by Visual Studio. I can assign property values to the control in the XAML, so it sure seems like all is good and it is seeing it.
  
• F6-compile and I get this error that the namespace doesn't exist. Yet the XAML doesn't show any of the indicator hints that it has a problem with this (IE: No red squiggles under the code and ReSharper isn't flagging a problem). {How can it NOT exist? I can see it. VS just let me drag it to the window. It even helped me by adding the XAML shortcut xmlns:my="clr-namespace:CwpfLib;assembly=CwpfLib"}

So I try plan B: Take it off the XAML designer and see if the C# code behind can see the namespace and the control.
Yep, it sees them and lets me type away to add the control through the code behind. As you can see Intellisense can see the namespace and the controls therein.

So I finish making and adding a TextBoxWithEllipse through C#.
Compile and once again, the code editor shows no indicators that it has a problem with this code or namespace yet the error window says it can't find the namespace.

Yes the assembly name matches and the C# making the TextBoxWithEllipse matches:

I figured that the original control library project must have suffered some damage on the drive, so I made this all new library, no copied files from old one: Its pristine. But the same problem exists. At this point it makes me start to double Visual Studio.

I've done all the suggestions I can find about deleting the .g.cs generated files so they are re-created. I've cleaned the project, quit Visual Studio, rebooted, loaded the solution and built it... no joy.

It doesn't get much more straight forward that make a control library, make a control, and reference, drag control to application window, run...

I feel like I'm coding Schrodinger's Cat: The namespace and controls are both there and not there at the same time. The designer and editor sees them while the compiler seems not too.

Does anyone see anything I could have missed?

[tlhIn`toq]

Isn't it always the way that after a day of pulling your hair out, then writing for help at your whit's end that you find the problem and it is something simple?

Hopefully this will help the next person suffering the same inexplicable misbehavior.

The class library was set to .NET 4 (full)

while the testapp project was set to .NET 4 Client Profile.

I must admit that I still find it baffling that the application project can so freely and without warning dialog drag-n-drop a control from a higher rated framework and blissfully work with it.

That is one of those lessons that will stick. All day long on this. I've rolled back to various back-up versions... lobotomized code to find issues... All for a framework version mismatch.

[eclipsed4utoo]

I ran into that same issue recently.

[tlhIn`toq]

Sorry you had to go through anything similar to me going through that.
I hope you found it in a lot less time and code destruction.

[eclipsed4utoo]

It took a couple of hours before I decided to actually look at the target framework. Not sure why I even looked there, but I thought it was retarded.

[tlhIn`toq]

Agreed. Retarded is the best term. If one drags a 4.0 control on a lesser rated designer canvas I would expect a message to pop up:

Quote

"The control comes from a project of higher framework version than the destination project."

[eclipsed4utoo]

And, if I am not mistaken, UI projects default to the .Net 4.0 Client profile, but a Class Project defaults to the .Net 4.0 Full. When this happened to me, I hadn't set either one, so they were just defaulting to different profiles.

[tlhIn`toq]

Bingo!