Click here to Skip to main content
14,879,577 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
I'm writing a WPF app using VS2013. I used NuGet to add the WPF Extended toolkit to my app. At home everything works as expected, but at work, weird stuff happens.

The project references are not showing an error, and the xmlns entry (that was automatically added to the XAML when I added a given control for the xceed toolkit) is not showing an error, but everywhere in the XAML that I try to use a control from the toolkit, it says the control doesn't exist in the namespace. However, if I instantiate one of the controls in the code-behind, everything is fine.

There's nothing weird about this solution (that I'm aware of). It's located on a local drive and the solution's projects (including the added nuget package) are all in a single folder, so I know when I transfer the code from work to home and back, all the code/projects/packages are contained in the ZIP file.

The code compiles with XAML errors, but runs fine.

Again, this does NOT happen at home, but DOES happen at work. WTF?

What I have tried:

I tried removing the package and adding it back, but that didn't have any affect.

I also tried removing all references to NUGET and just added the DLL references to my app. This also had no affect.

At work, we have problems accessing This is a network issue that can only be fixed by the IT idiots. Thinking this might be the issue, I cleared the package cache and turned off the nugget update on startup feature. That also had no affect.
Updated 6-Jul-17 11:23am
Erik Rude 6-Jul-17 10:32am
Have you checked you're targeting the same .Net framework in both solutions? Just a wild punt.
#realJSOP 6-Jul-17 11:17am
The app I'm writing s 4.5, and the library is compiled for 4.0. The .Net version is not the issue. Remember, it works on my home computer, but does NOT work on my work computer. I'm using the same version of visual studio and home and work, and they're both patched up to the same level.
Erik Rude 6-Jul-17 11:19am
I've had WPF an VS behave oddly when I accidentally had different targets for different projects in my solution, so just hoped it was that simple. Otherwise no brainwaves from me sorry.
Richard Deeming 6-Jul-17 11:19am
Have you tried cleaning and rebuilding the project? It almost sounds like the files in the obj folder are missing or out of date.
#realJSOP 6-Jul-17 11:46am
Over and over again. I have all binaries being put into the ..\bin\debug folder. After doing a clean, I have to shut down the IDE, manually remove each project's obj folder, and manually delete the ...vhost.exe.config file to get a pure clean.

1 solution

I couldn't do this at work, but when I got home, I checked the file properties, and I was able to UNBLOCK the DLLs. I'll zip everything back up and send it back to work to see if that fixed it.
Dave Kreskowiak 6-Jul-17 19:17pm
Government contractor?
Richard Deeming 7-Jul-17 11:35am
If you send the zip file via email, it will probably get blocked again. :)

Make sure you unblock the zip file before extracting it. There isn't a built-in way to unblock all the files after you've extracted them.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900