WPF xaml files go missing after build in Visual Studio 2013

[Anonymous]

We are experiencing a problem within Visual Studio/Revit when building our solution that includes WPF's and xaml files.  For some reason, unknown to us, our computers will randomly "lose" the xaml file associated with a WPF.  We have searched all over for others experiencing this smae issue, but are coming up blank.  So I am hoping that a specific post here might help us get an answer.  So far, this issue has happened on two different computers with different logins (and profiles).  All the while, other computers can build and run the solution in Revit even after the other computers "break".

We are using Visual Studio 2013 and using Team Foundation Source Control and programming in Revit 2015.  The computers in question are running 2015R2(2015UR4) and 2015UR3.

As far as we can tell, everything is in order regarding the files remaining in place within the Visual Studio workspaces and etc.  We have removed the solutions from the computer and pulled down all code again from Source Control, copied Visual Studio workspaces from one computer to another and the problem remains.

The error we recieve is included below.  I have also attached the three files in question (MainWindow.xaml, MainWindow.xaml.cs, and TicketManager\TicketManager.cs) as a single zip file in the event it helps.  

Any help or points in the right direction would be greatly appreciated.

System.IO.IOException: Cannot locate resource 'ticket%20tools/ticketmanager/views/mainwindow.xaml'.

   at MS.Internal.AppModel.ResourcePart.GetStreamCore(FileMode mode, FileAccess access)

   at System.IO.Packaging.PackagePart.GetStream(FileMode mode, FileAccess access)

   at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)

   at EDGE.TicketManager.MainWindow.InitializeComponent() in d:\Visual Studio 2013\Projects\EDGE\EDGE\Ticket Tools\TicketManager\Views\MainWindow.xaml:line 1

   at EDGE.TicketManager.MainWindow..ctor() in d:\Visual Studio 2013\Projects\EDGE\EDGE\Ticket Tools\TicketManager\Views\MainWindow.xaml.cs:line 26

   at EDGE.TicketManager.TicketManager.Execute(ExternalCommandData commandData, String& message, ElementSet elements) in d:\Visual Studio 2013\Projects\EDGE\EDGE\Ticket Tools\TicketManager\TicketManager.cs:line 21

Thanks,

Keith

[GonçaloFeio1321]

What is the Build Action property for mainwindow.xaml?
It should be Page.

[Anonymous]

Thanks for the reply.  

Unfortunately, the build action is set to Page and has not been edited.  The problem seems to be with the building actions in VS.  We have reviewed one of the problem computers (laptop) with a workstation that still compiles just fine.

One thing to note is that when the problem computer (either of the two) builds the solution, all WPFs fail to be found.  not just the Ticket manager WPF that I referenced in the original post.

I will go even further into comparing settings, options, and etc. today and drill down as far as I can go to determine where the offensive setting or action is triggering the problem.  Hopefully I can find something that makes a difference.  One problem is that most internet and MSDN links referencing problems with xaml refer to build exceptions and complete xaml projects.  We are working in a cs project with some WPF xaml windows as forms in it.  So the typical xaml problems noted on the internet are not relevant to our problem.

We even went through the process of uninstalling VS on one laptop and reinstalling with no positive outcome.  

I will post again when I finish my review and relay any information I gain.  I appreciate the response and welcome any other suggestions.

Keith

[Anonymous]

Update:  

I still do not know what is happening to cause our missing xaml at runtime problem. However, it appears to be a windows or Revit issue and not a Visual Studio issue.  I looked everything over yesterday and could not see any differences in the settings between the two computers.  So I built the solution again on my laptop (offending computer) and then copied the dll files and folders to my workstation (non-problem computer) and the WPF runs without a problem o nthe workstation when it did not on the laptop.  

So this leads me to believe that something has changed on the windows system or Revit in the last few days on both of these computers (albeit individually and separately) which is causing the problems we are having.  

While this is not the situation I want/need right at this moment, it does make me feel a bit better (very little) about the WPF usage in our very large programming project.  Now I have to figure out what is happeing in windows/Revit that is causing the issue...

To be continued...

Keith

[Aaron.Lu]

I did not reproduce the problem, but would you mind try this: http://stackoverflow.com/questions/7126147/ioexception-was-unhandled-cannot-locate-resource-app-xaml

[Anonymous]

Thanks for the stackoverflow suggestion.  Unfortunately, we have already been through many stackoverflow suggestions with no success.  I will post a separate reply with the solution we found.

Keith

[Anonymous]

Solution for me (even though it is not a simple nor easy one):

I ended up having to perform a full Windows reinstall to clear the problem.  Now everything seems to be performing and operating as planned on the offending machine.  

Prior to performing the full system wipe, we tried everything we could think of and had no success.  

We think that the problem originated from copying and pasting code from a version of the tool code that was being edited on the local computer only (non-source controlled) into a class file in the project that is being source controlled.  I don't know what underlying problem this could have been causing, but in each case where the computer didn't like the WPF it was sometime after code had been copied and pasted (even though the problem did not present itself immediately).  Its very strange and we could not trace the root of the problem in any definitive manner.

So, our takeaway is to not copy and paste WPF xaml code in the future.  

I don't like having to to resintall Windows, but that is what solved the problem for me...

Thanks again for all of the suggestions and offers for help.

Keith

[Anonymous · Accepted solution]

OK.  We now know the real problem and the real solution or our WPF and xaml file issues.  We have had this error occur again and this time we used a powershell script to scan the C:\ drive to tell us what files were edited in a specific time window that corresponded to the problem occurance.  

Our script revealed a file that was created/edited using SharpDevelop via Revit that was similarly named to one of our Visual Studio Projects and thereby creating a naming issue.  In order to test some code snippets prior to committing them to our full Visual Studio solution, a macro module was created with some code inside.  That module was named the same as one of our Visual Studio Solution projects which were being loaded as dlls in our Revit sessions.  The SharpDevelop macro was also creating dlls and placing them in a buried and hidden folder and Revit was having issues with the two dlls being named the same thing.  

We are using Revit 2015, so our macro folder references a folder specific to that version.  For us the macro folder containing the offending dlls was:

C:\ProgramData\Autodesk\Revit\Macros\2015\Revit\AppHookup\

Deleting the offending files in this Macros folder and also from the SharpDevelop interface, as well as a Revit restart, resulted in our WPFs using xaml opperating correctly once again.  So, no need to reinstall software or anything more than a big sigh of relief.

Hopefully this information may be found valuable to someone else at some point in the future.  It was surely painful to discover for us, even though it seems painfully obvious now...

Keith

[Aaron.Lu]

Great Keith,

It is really valuable, thanks to post it out!

[Troy_Gates]

Just wanted to say thank you for figuring this out. I ran into the same issue today of having a macro with the same namespace as an addin. This caused all WPF to be non-functional.

After deleting the macro of the same name, all is well again.

[Anonymous]

Troy, please clarify. Do you mean ALL WPF in every add-in or just one add-in? When was the WPF non functional? Does this non-function happen within the IDE as implied by the original post or does this happen when executing within Revit? I ask because this is disturbing.

It has been my understanding that namespace is a convenience for the compiler and therefore as such would not exist within the final product. Do I have this wrong? The Revit add-in product I see and distribute is a single dll file. Whatever information that is in the WPF files used when creating that dll file no longer exists in its original xaml file form. It is just the dll and the manifest that need to be present for the add-in to function. Maybe the xaml is encapsulated somehow in the dll, but to be upsetable by having an arbitrary text name in common with something else is hard to believe. Does not that seem like a very serious design flaw?

The original posts say, "go missing after build", without explaining that the build did not result in the files going missing. I suspect the build action did not remove the files. Something else did after the build but not as a result of the build. What actually is happening does not appear to be resolved. It is like we are rubbing some chicken bones together as the solution. 

[Troy_Gates]

What happened to me was that I have been updating some addins to WPF from Winforms and also to 2017 from 2016. So everything was working great when I would compile the solution and run in Revit 2017. But when I went to test it in Revit 2016, none of the WPF forms worked, they all gave exception errors when I debugged them while the Winforms worked as normal.

I knew it had to be something with the WPF (XAML) files. So after a long search I finally came across this forum post. I checked in my Revit 2016 macros and there was a macro with the same namespace as my addin. After removing the macro (I only use it for testing so wasn't important to keep), I restarted Revit and all my WPF addins worked as expected.

Lesson learned, don't name macros the same as your addins.

[keith_white]

I am glad that this thread served as a help to you.  I experienced this issue prior to joining Autodesk and it had us at our wits end.  It was so frustrating until we realized what was happening.  Once we discovered the reason for the issue, it made absolute sense.  

Hopefully others will also come across this thread if a similar experience is encountered for him/her.

Good luck as you continue onward!

Keith