Develop Reference

Why does my release build fail with error APPX0002: Task 'ValidateAppxManifest' failed?

I am trying to develop a UWP app for Windows desktop machines. Everything has been going well, but within the last few days I've lost the ability to build a release version (building a debug version still works fine).
I get the following error messages:
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.AppXPackage.Targets(2810,5): error APPX0002: Task 'ValidateAppxManifest' failed. Unspecified error
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.AppXPackage.Targets(2810,5): error APPX0002: [My App] violates pattern constraint of '\bms-resource:.{1,256}'.
I've tried a number of "fixes" that worked for people over the last few years. Some people report the problem fixed itself in the latest version of Visual Studio. Unfortunately, the versions they mention are older than the version I'm using, which is
Microsoft Visual Studio Community 2019
Version 16.6.3
Many fixes from the net are similar to the ones below, from the URL
https://social.msdn.microsoft.com/Forums/en-US/4cc2cbfb-fa0d-4f12-a0a1-9072d78e26d6/vs2019-error-task-validateappxmanifest-failed-unspecified-error-again-and-again?forum=msbuild
One fix was:
Clear nuget packages,
Clean solution
Close VS
Delete bin & obj folders of the main (startup) project
Open VS - solution
Restore solution nuget packages
Rebuild 'n go
Another fix was:
uninstalling vs & sdks,
removing every nuget folder,
clean the registry and restart the system,
the last step once more,
reinstall vs.
I have tried all of these (several times) except for "clean registry." I'm not sure what part of the registry we're talking about.
So, has anyone overcome this problem in a different way, or know what the registry idea is?
Oh, some other data is
Maybe my machine is too old (about 6 years old). I’m speculating that even if my machine seems to have the latest version of Windows an Visual Studio, maybe it doesn’t have exactly the latest code.
Things went bad while I was adding two new features. The first was to ask the user for a rating, via _storeContext.RequestRateAndReviewAppAsync(); The second was allowing the user to share some data via DataTransferManager.ShowShareUI();
I was thinking maybe these APIs might require some declarations in the manifest that I don't have, but I don't see from the documentation that they do.
Any ideas would be greatly appreciated. I’m out of ideas at the moment.
Dan

Here is the answer, for me. I’m not confident that this as the answer for all cases, but all is good now.
You may remember that I said I had the latest version of Windows, and I did. However, when I checked with Windows Update last night, it confirmed I was “up to date” but it offered me a “Feature update” to Windows 10, version 2004. I decided to go for it.
The update took hours to complete, and this morning it was still only 94% complete when Nico Zhu suggested to try using Visual Studio 2017. I figured I’d install VS 2017 after the update, but when it was finally complete, I decided to try VS 2019 one more time with my fresh new version of Windows. Amazingly, it worked the first time.
I should mention that my new procedure for making an app package now includes
close VS 2019
delete the project’s obj folder
delete the project’s bin folder (I used to just delete the obj folder, but after seeing others suggestions I’ve added this step)
launch VS 2019
create the App Package
I wanted to do another build/package so I fixed a couple of cosmetic bugs and tried again. On the second try I fell back into my old pattern and I did NOT delete the bin folder. Immediately VS 2019 popped up with an error message something like “Cannot complete build. Fix problem with your app manifest.” Rather than pouring over the manifest file as I’ve been doing for the last couple of days, I deleted both the obj and bin folders and tried again. The build/package process then worked perfectly.
So, I want to say that the app manifest file was not the culprit (in this case anyway) and I’m now a fan of deleting both the obj and bin folders, and having Win 10 version 2014, before attempting a release build with VS 2019.
Dan

Visual Studio 2015 diagnostic tools no longer working

I have Visual Studio 2015 Community Edition Update 3 running on Windows 7 SP1 64 bit, which I use to develop C# applications.
I love the diagnostic tools during debugging to spot performance problems early on. However, they stopped working for me sometime in the last month or so (possibly related to installing Update 3, although I have no information to back that up). I see the error message "CPU Profiling while debugging is not available on this version of Windows. To see CPU usage details, run the CPU Usage tool without the debugger (Debug -> Performance Profiler...)."
Things I have tried without success:
Completely uninstalling and reinstalling VS.
Performing a repair on my VS installation
Ensuring "Use {Managed,Native} compatability mode" is disabled in debug options.
Enabling the Diagnostics Hub logging info as described in this question. No error messages that I can see appear in the logs.
This still happens even if I create a new WPF project, so I don't believe it has any project-specific cause.
Are there any other things I can try? Obviously they were working before, so I don't believe the error message about my version of Windows being unsupported.

Deleting my solution's .suo (solution options) file fixed the issue. My initial statement of this bug affecting even new projects seems to be wrong. Although, I did do a complete reinstall of VS after doing that test, so it's possible that impacted the outcome.

Full disclosure: I work at Microsoft, specifically on the Diagnostic Tools team.
There are parts of the Diagnostic Tools that won't work on Windows 7, specifically taking a CPU profiling trace while debugging. This is a limitation of the operating system and ETW. If you are just interested in the graphs and debugging events, those should work. You can turn on logging for our tools which might give you some insight into why they are not working:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0\DiagnosticsHub\LogLevel
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0\DiagnosticsHub\LogDirectory
For LogLevel you can use one of the following strings "All", "Info", "Debug", "Warning", "Error" (In your case I would use All to better see what is happening). As for LogDirectory it is a directory of your choice "C:\Logs". When your done reproing the scenario, close VS to flush the logs and don't forget to delete these keys as the diagnostic tools logging is pretty system intensive.
You should be able to search for "Error ---" in the logs to get an idea of what is happening. We have seen problems with certain VS extensions and custom projects.
Also, feel free to also post the issue at: https://connect.microsoft.com/ Each issue that is received there gets turned into a bug and assigned to the corresponding team.

I had som issues with that a while ago.
1) Check Tools>Options>Debugging>General>Enable Diagnostic Tools while debugging
2) Check Tools>Options>Intellitrace>Enable intellitrace

I had the same issue, although deleting the .suo file did not help, I also repaired Visual Studio 2015 Professional and then it worked. So for future readers, if deleting the .suo does not help, try to also repair Visual Studio and vice versa.

None of the others worked for me. What I had to do was close all Visual Studios and re-opened it and the diagnostic tool worked.
(I deleted the .suo file, made sure all the correct options were enabled, but because I had another Visual Studios session running, none of it worked until I closed all)

I had already another visual studio instance running with diagnostic one. That was the issue for me.

I faced this problem today and it was not easy to find working solution.
This helped to me:
Reinstall Cumulative Servicing Release for Microsoft Visual Studio 2015 Update 3 (KB3165756)
Direct link to download: http://go.microsoft.com/fwlink/?linkid=816878.
After Repair action (I had it installed before, otherwise install) prompted to restart computer, did it and Diagnostic tools worked again.

I had a similar problem with Visual Studio 2015 Pro Update 3 running on Windows 10 Home. The runtime display of memory and cpu usage stopped working. Deleting the .suo file fixed the problem, as indicated by proc-self-map's answer. The .suo file was buried in the .vs hidden directory so I removed the whole .vs subdirectory. Now the runtime display of memory and cpu usage works like a charm again. No reinstall required.

Visual Studio 2013 or 2015 EditorPackage did not load correctly constantly

When starting Visual Studio 2013 Pro (Update 4 installed) I very often get this error message (several times a day now) for the past about two weeks:
The 'Microsoft.VisualStudio.Editor.Implementation.EditorPackage' package did not load correctly.
I know I can correct this problem by closing Visual Studio and deleting:
%LocalAppData%\Microsoft\VisualStudio\12.0\ComponentModelCache
I have never seen it before that time and as far as I found out in the Internet it was possibly introduced with Update 3.
Well, the problem is that it is annoying to restart Visual Studio several times a day, and I was wondering if anyone else is experiencing this and knows how to solve it for good or what the cause is.
I noticed that it happens extremely often if I work in more than one instance of Visual Studio in parallel. This one is a killer. But still I suspect a third-party component to be involved or it is the size of one of the solutions (about 70 projects). I tried to deactivate some extensions I newly installed and need for the big project, but to no avail.
Just as information: I am working with C#. When working in parallel with projects open in several instances of Visual Studio I never had problems before.
Does anyone have the same problem to this extend or possibly have a better solution than deleting the folder and restarting?

This has become a popular question so I thought I add an explicit answer how to (at least) temporarily fix the problem as already stated in the question:
I stop Visual Studio and delete the following folder (completely, not just contents)
%LocalAppData%\Microsoft\VisualStudio\12.0\ComponentModelCache
If you are using VS2015, then the path should be:
%LocalAppData%\Microsoft\VisualStudio\14.0\ComponentModelCache
If you are using VS2017, then the path should be:
%LocalAppData%\Microsoft\VisualStudio\15.0\ComponentModelCache
I don't keep a backup of the folder. It is created automatically again when starting Visual Studio.
I have never found a solution how to permanently fix the problem in that working environment. In my new developing environment (new projects and new workplace) the problem never happens.

This is what helped me... seemed to happen after Windows Server 2012 SP install...
https://connect.microsoft.com/VisualStudio/feedback/details/1123745/setsite-failed-for-package-microsoft-visualstudio-editor-implementation-editorpackage
devenv /clearcache
devenv /updateconfiguration

In that case you can start Visual Studio setup again and choose the option showing two options, Repair and Uninstall. Then click Repair and when repair is done, restart the computer. Then the issue has been resolved.

Can't compile because Visual Studio is using my DLL

I have a rather large .NET 2.0 solution (151 projects) in Visual Studio 2008. Often times when I do a build (even for just one project) in VS I get an error saying that it can't copy one of my DLL assemblies to the output directory because it is in use. I don't have any other processes running in the background or existing debug sessions going that would be using this assembly. If I open up Process Explorer and do a search for this assembly name Visual Studio (devenv.exe) comes up as the only result. Looking at the results Visual Studio has my assembly loaded as a DLL for some reason. Closing the solution and reopening it doesn't solve the problem. I have to completely exit out of VS altogether to get around this issue which is quite disruptive. Does anyone have any idea what is going on? I'm running on Window 7, I don't think I saw this issue on Windows XP.
I am running Visual Studio 2008 Version 9.0.30729.1 SP. I'm also running ReSharper 6 if that matters.

Does anyone have any idea what is going on? I'm running on Window 7, I
don't think I saw this issue on Windows XP.
I run into this problem all the time on Windows XP and its not even localized to Visual Studio 2008. What always works for me is I simply clean all solutions, this gets rid of any file that might be in my system's memory, because of Visual Studio.
Visual Studio keeps any your references in memory, so when one of those references is updated, Visual Studio has to release it from memory. If it really happens more then "once in awhile" then you might look at trying to reduce the number of solutions in your project.

Use the following command and place it in "Pre Build Events" of visual studio:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
Hope this would help you.

Try to disable the hosting process:
Open an executable project in Visual Studio. Projects that do not produce executables (for example, class library or service projects) do not have this option.
On the Project menu, click Properties.
Click the Debug tab.
Clear the Enable the Visual Studio hosting process check box.

Kill process VBCSCompiler.exe and rebuild.

I would guess that the dll is being used by the (ProjectName).vshost.exe process. You might try killing that process and see if that works. Probably not the best thing to do, but it might be easier than restarting VS.

I would try the "Clean Solution" option before you build. This can clean up any extraneous temp files that could be hanging around from a program crash.

I have no idea about why this works, but I had the same problem and when I changed the Starting Project to the project I wanted to build everything worked again.
When I change the Startup project again to the right one I cannot build the other project anymore due to the file being in use, so looks like a bug at the Visual Studio IDE.

Error Creating Debug Information - Code Won't Compile

I'm using VS 2008. When ever I make a change in my code and try to compile I get the following error:
Error 7 Unexpected error creating
debug information file 'C:\Documents
and Settings\jbezanson\My
Documents\MyProjects\DispatchBoard\DispatchBoard\obj\Debug\DispatchBoard.PDB'
-- 'C:\Documents and Settings\jbezanson\My
Documents\MyProjects\DispatchBoard\DispatchBoard\obj\Debug\DispatchBoard.pdb:
The process cannot access the file
because it is being used by another
process. ' DispatchBoard
Using Process Explorer, it is always devenv.exe that is locking the file. If I run in Release mode this does not happen. It started 2 days ago when I started a WPF application, and since then it happens with every application I work on.
The only info I could find from Google was referring to a bug in VS 2003.
Anyone else have this problem? How do I fix it? It is getting very annoying having to kill the file handle every time I want to compile.

If you have multiple instances of VS open, close other instances (apart from the one you are trying to compile) - this may resolve the issue.

When I have problems with locked files, I use Unlocker. (If you tried everything and it's not working, try this ;)
In case of broken link, here's a mirror.

Have you tried closing VS, deleting obj folder then restarting VS?

I had the same problem this morning and noticed that I had another project open that had a reference to the one that would not compile or debug. I removed the reference (as I didn't actually need it) and it was fine.

I changed the 'StartUp Project' of my solution to a project without reference to the locked file's project.
This solved the issue for me using VS 2010 SP1.
(Process Explorer said msvsmon.exe (started by devenv.exe) locked the pdb file.
After changing the startup project the processes msvsmon.exe and .vshost.exe disappeared and so did the file handle.)
Alex Clark, thank you for pointing me in the right direction.

The only thing that worked for me is to remove the optimizeCompilations="true" attribute from on the compilation element in my Web.Config file.
Compilation time may be a little longer, but it worked well.

To avoid that problem just open the project properties, go to Debug tab an untick "Enable the Visual Studio hosting process"

I had this issue today. In my case, I had just grabbed the data from my company's source control and instantly hit this issue when I tried to compile the project. The issue ended up being that the \bin folder was set to Read Only. To solve the issue, I just made the folder not Read Only.

I just came across the same problem today. And then I realized what went wrong: I had couple of Visual Studio windows opened at the same time, and one of them was in debug mode.
When I stopped debug mode in that one, the problem was solved.
That happens when you have a "fistfull of VS windows" opened.

Right Click The Folder that contains debug .pdb and uncheck the folders read-only propertys then ok. thats it.

This works for me with web projects in Visual Studio Express 2012 for Web:
Press F5 to begin debugging
"Do you want to execute last successful build?" - hit YES
At this point you could try a request - not sure if this step is necessary
Hit the stop button
Recompile successfully

I have solved a similar problem by adding these lines as a pre-build event:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
With proper modifications, it might help your problem.

Since you say you have it on all applications you work on it sounds like a more global problem. You could try and reinit the vs2008 by writing
devenv.exe /setup
Edit: link to command line options

This worked for me. What I done was that close my visual studio and delete the .suo file and then re-open the solution. The locking should be disappeared now. Cheers.

Old topic, but something that worked for me. I had 2 projects in my solution, a class library type project and a windows form project. The windows form project was referencing the compiled binary and not the project itself in my case which was causing the lock. After changing the reference to the class library project, it worked properly.

Not need to restart or delete the file.Deleting will not be possible , you will get error message. Just rename the file and that is enough.
VS2010 will create another file for you as it wont find the origional. :)

I had the same issue from time to time. Usually no problem but once in a while... This particular time, it was impossible to work. I would shut the application down, and even that didn't work most of the time. I saw this post and a person said they had no issues until they started a WPF application. I was playing music (radio station) in the background with Windows 8 "Music" app. I had the idea that it was a Microsoft App built with Visual Studio. Once I stopped playing music, I never encountered the error. If you are reading this, see if you have any Microsoft apps running.

I also had the same issue. Tried all the suggestions above with no luck. I eventually change the Build Configuration from Debug to Release, the solution built...

This problem started occurring for me after changing from Cassini to IIS Express as my platform for debugging.
Cassini was much better than IIS Express but doesn't properly support the Integrated pipeline. IIS Express is hopeless.
This seems to be some sort of race condition in Visual Studio or IIS Express. It is nothing to do with one project locking another project - the locks are coming solely from the activity of the web application's build process.
Anyways, none of the above solutions worked for me. Unlocker doesn't seem to be supported for Windows 8 anymore. So instead I tried LockHunter. What I do is keep the LockHunter app open all day. If I get a complaint about some file being locked I copy and paste the file path into LockHunter then try again. This usually sorts out the problem but sometimes takes a few attempts.