Related
Code: https://github.com/ToadallyAwesome2/ComettTest
So I am using Maui/Comet. I just want to run a sample project, but I get this error:
DEP0700: Registration of the app failed. [0x80073CF6]
AppxManifest.xml(33,27): error 0x80070003: Cannot install or update
package BF12F2F8-C129-4401-821A-69268F23ED72_9zz4h110yvjzm because the
splash screen image [appiconfgSplashScreen.png] cannot be located.
Verify that the package contains an image that can be used as a splash
screen for the application, and that the package manifest points to
the correct location in the package where this splash screen image can
be found.
Anyone knows what I can do? I tried making an assets folder with that png, but it didnt work.
UPDATE
Did what Gerard Versluis recommended and got the following error:
DEP0700: Registration of the app failed. [0x80080204] error 0xC00CE020:
App manifest validation error: The app manifest must be valid as per
schema: Line 26, Column 8, Reason: Het vereiste kenmerk
Square150x150Logo ontbreekt. CometApp1
translation: The required attribute Square150x150Logo is missing.
I notice that it keeps asking for the Square150x150Logo
This happens because of change in one of the previews. Long story short; we used to have an Assets folder for the Windows app, but not anymore. Since it's all in preview there wasn't a concern for backwards compatibility, but now this could occur.
It happens because you probably started a project earlier, with older templates, and are now trying to build against new preview bits. So in the templates the Assets folder is still mentioned, but is no long there.
The steps to take are also described in the preview 13 migration guide.
Go into the Platforms\Windows folder and open the Package.appxmanifest file. Right-click > Open With... and choose the XML editor
Remove all references to Assets\
Double-check your App.xaml file to see if there is a windows:Application.ImageDirectory attribute on the Application node. If so, remove it. For example:
<Application xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:windows="clr-namespace:Microsoft.Maui.Controls.PlatformConfiguration.WindowsSpecific;assembly=Microsoft.Maui.Controls"
windows:Application.ImageDirectory="Assets"
x:Class="WeatherTwentyOne.App">
should now be
<Application xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
x:Class="WeatherTwentyOne.App">
After that, it should work again!
To make sure it doesn't happen again, make sure that you have the latest templates by running dotnet new -i Microsoft.Maui.Templates which should get you the latest templates that do not reference Assets anymore.
this was the only solution than worked for me:
https://developercommunity.visualstudio.com/t/mauiapp-cannot-run-on-windows/1670999
Pasted below:
Upgrading the maui templates using
dotnet new --install Microsoft.Maui.Templates::6.0.200-preview.13.2865
solves this issue when creating a new MAUI App.
It would be nice, if the process of upgrading VS could include updating the MAUI templates or maybe warn about the need to manually update 😃
In case of an existing MAUI App project - these changes worked for me:
remove all references to the ‘Assets\’ subfolder from the Platforms\Windows\Package.appxmanifest file
add a line about raw assets to the .csproj file in the ItemGroup that contains the MauiIcon, MauiSplashScreen, MauiImage, MauiFont tags:
<ItemGroup>
...
<!-- Raw Assets (also remove the "Resources\Raw" prefix) -->
<MauiAsset Include="Resources\Raw\**" LogicalName="%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>
delete your .vs/obj/bin/.csproj/.sln, and then dotnet new maui --force right inside that same folder. that fixed this issue for me, and this randomly happened to, but i think it was due to me updating some workloads. im also sure my project template was still on preview 9 lol. its always best to be on the latest template for each preview.
EDIT: if you modified your App.xaml/App.xaml.cs and/or MainPage.xaml/MainPage.xaml.cs, youre gonna need to save those so you can put them back. dotnet new maui will need to overwrite some things. unless you delete them, but theyre just things generated by the template. anything generated that you have modified, will need to be saved and updated.
After searching the SO forum, I cannot find a working solution for my question. If you find one, I would really appreciate it.
In Visual Studio 2012, I am building a C# project. I get the following error:
Source file 'Properties\Assemblyinfo.cs' could not be found.
I have this solution:
Source file 'Properties\AssemblyInfo.cs' could not be found
But, it does not work for me.
Actually, I have the 'Assemblyinfo.cs' in working directory, I can see it in VS solution explorer.
Have you tried deleting the assemblyinfo.cs files and then trying Clean and Rebuild solution? If you don't need versioning this might help you.
Have you tried a Clean Solution, followed by a Rebuild Solution?
The AssemblyInfo.cs file should be recreated on a build.
I got this error even after I tried to Clean and Build. I could also could see the AssemblyInfo.cs file. I found out that the build was interacting with a power shell script(not entirely sure how) in the solution directory.
Long story short, Every project, except the one I had added(where the problem was), was mentioned in that script. I added the missing info to that script and I could build again.
I doubt your case will be exactly the same, but I imagine there could be some script or something similar that handles/references all the projects, except the one where your problem persist. Try searching the files for the text of project names.
I have encountered this situation.
I find out why. It is usually due to confusion between mscorlib.dll versions.
There are two ways:
Change assemblyinfo version from 1.0.0.0 to 1.* (change value to *). See link:
MSBuild extensions AssemblyInfo fails with version number not valid
Get an error when trying to set the build version with the AssemblyInfo Task
The second way is simple, I have applied it successfully, that is reinstalling .Net Framework 3.5.
Clean and Rebuild did not help for me.
What helped was manually deleting ALL /obj and /bin files and then using Clean and Rebuild.
I have been wrestling with the Android Calendar for a couple of days now and I'm at my wit's end.
Following the instructions found here:
http://docs.xamarin.com/guides/android/user_interface/calendar/
I have begun a new ICS project and added permissions to read and write to the calendar. According to the instructions linked above I should now be able to "interact with calendar data by using the CalendarContract class." However, when I input the first line of example code:
var calendarsUri =CalendarContract.Calendars.ContentUri;
I get an error saying that "The name 'CalendarContract' does not exist in the current context."
I have download sample code for the CalendarDemo located here:
http://docs.xamarin.com/samples/CalendarDemo/
I can open the project, manipulate the code, deploy it to my test device with the modifications that I have made and it works perfectly. The problem is that I cannot seem to get CalendarContract to "exist in my context" if I create a project from scratch. Even adding in the CalendarListActivity.cs into a new project won't work. This leads me to believe that there is something I have to set in Xamarin Studio, not via code and not indicated in their tutorial, that I have yet to find.
What setting or reference do I need to add into a new or existing project in order to use this feature? I've looked everywhere I can think of and cannot find the elusive switch, checkbox, reference or whatever is required. I've burned three days trying to figure this out and I have lost my patience.
I was able to reproduce the error you're having. I created an ICS project in Xamarin Studio and got the same message. I then loaded the solution in Visual Studio and noticed that the CalendarDemo project has a reference to Mono.Android v4.0, but the one created in Xamarin Studio only referenced Mono.Android v2.2 even though I specified Ice Cream Sandwich. That is why you're not able to build.
Changing the Target version in Project Options didn't seem to do anything. A workaround is to add
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
to the .csproj file. See the CalendarDemo project as an example.
BTW: This is on Xamarin Studio v4.2.2 (build 2). I don't normally use Xamarin Studio, so I have never had to deal with this. I'm not sure if it's a bug in XS, but it certainly isn't expected behavior.
Just as a test, I created another project in Xamarin Studio, but this time I just selected the standard Android Application project. Surprisingly, it referenced Mono.Android 4.3.0. So apparently there's a bug in the Android Ice Cream Sandwich project template.
I recommend using the standard Android Application project going forward.
If you are using Xamarin Studio, right-click on CalendarContact and select Resolve. It should give you two options, first will add "using Android.Provider;" to your using statements and the second will append the code to "Android.Provider.CalendarContract.Calendars.ContentUri"
...or just add manually the using statement. :)
You should import this library
> using Android.Provider;
> using Java.Util;
The RC class is not linked to a database, it is a simple class. The class is at only one place and is not partial. The Aérochem.Domain dll project compiles just fine.
Note: If I select one of the two identical namespaces in the quick fix menu, it does nothing.
Note2: This happens to a couple of classes (some related to a database, some not)
Is there a fix to that or a way to figure what's wrong?
I had the same problem. I use ReSharper. The solution to my problem was not cleaning the solution but deleting the suo-file.
Hope that helps.
As for the reference of any future users: This thread covers four answers whereas two are in the comments. I have faced the issue several times, three of these answers have helped me in the past, so if you face the same issue, try any of these:
Clean and/or Rebuild the Solution then reanalyze the files in Resharper.
Restart Visual Studio then reanalyze
Delete the bin/ folder then reanalyze
(Apparently deleting the suo-file can help, too, although I never had to do that and can't understand how it should help)
A combination of the three above.
(This is not really a new answer, it is more of a comment on the variety of answers and comments found - it is a community wiki so feel free to adapt it if necessary)
For ReSharper users that, like me, don't want to delete their solution's *.suo file:
Clear your caches via: ReSharper -> Options -> Environment -> General -> Clear Caches!
Thanks go to AUSTX_RJL for his comment to this answer. I wanted to give his valuable info more visibility.
The .dll was already in my /bin folder.
When I deleted it, it got rid of this error.
I had this problem and also ReSharper installed on visual studio.
I open bug ticket on ReSharper tracker and the development team advised me to do:
Solution:
This problem can be solved by removing the Solution User Options (.Suo) File. This file is stored in the project root but is hidden. you need to check Folder Options-> View-> Show hidden files, folders, drives. and you need to close visual studio if you have open this project because is used by visual studio.
I had the same problem while two packages were ambiguously referencing the same dll, and this is what worked for me:
I have given an alias name to one of the packages (named Dapper.StrongName), by putting the following into my .csproj file:
<Target Name="ChangeNameAlias" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
<ItemGroup>
<ReferencePath Condition="'%(FileName)' == 'Dapper.StrongName'">
<Aliases>AliasName</Aliases>
</ReferencePath>
</ItemGroup>
</Target>
And then added the namespace as using AliasName::Dapper;
I added a post here: Ambiguous extension methods
See related articles:
extern alias (C# Reference)
:: operator (C# Reference)
C# 2.0: Using different versions of
the same dll in one application
For me it was because I had referenced the DLL both by Project reference and Assembly reference. Deleting the Assembly reference fixed the issue.
If your project structure contains more than one project under one solution, then you have to delete the content of the bin folder in every project. Doing so solved the error that i was facing.
In my case, i have referenced the proyect X inside itself. So the problem wasn't ReSharper (but it was ReSharper who added the reference...)
I had this problem in a .NET standard project (I call it the host project). The namespace causing the problem was in another referenced project (which was also a .NET standard project) in the same solution.
I did everything: clean, delete resharper cache, close soln, delete .suo, delete binaries. Nothing seemed to work.
Then I converted the host project to .NET framework and then the problem disappeared.
I know this is a pretty old issue, but maybe this will help someone. If using c# razor in Asp.Net Core 2+, if you have this problem.
1) Copy the content of the file to notepad.
2) Delete the .cshtml file.
3) Create the .cshtml file with the same name.
4) Copy the content from notepad into the new file
I don't know if this is just a weird bug, or a consequence of upgrading a project from Core 1.0 to 2+, but it FINALLY fixed the problem for me. This was an issue for me in both Visual Studio 2017 and 2019.
I had this issue in Rider, and going to File | Invalidate Caches | Invalidate and Restart fixed it for me
This is driving me crazy.
I have a rather large project that I am trying to modify. I noticed earlier that when I typed DbCommand, visual studio did not do any syntax highlighting on it, and I am using using System.Data.Common.
Even though nothing was highlighted, the project seemed to be running fine in my browser. So I decided to run the debugger to see if things were really working as they should be.
Every time the class that didn't do the highlighting is called I get the "the source file is different from when the module was built" message.
I cleaned the solution and rebuilt it several times, deleted tmp files, followed all the directions here Getting "The source file is different from when the module was built.", restarted the web server and still it tells me the source files are different when they clearly are not.
I cannot test any of the code I have written today because of this.
How can the source be different than the binary when I just complied
it?
Is there any way to knock some sense into visual studio, or am
I just missing something?
I got this issue running a console app where the source that was different was the source that had the entry-point (static void Main). Deleting the bin and obj directories and doing a full rebuild seemed to correct this, but every time I made a code change, it would go out-of-date again.
The reason I found for this was:
I had checked "Only build startup projects and dependencies on Run" (Tools -> Options -> Projects and Solutions -> Build and Run)
In Configuration Manager, my start-up project didn't have "Build" checked
(For #2 -> accessible via the toolbar under the 'Debug/Release' drop down list.)
I was just having this same problem, my projects were all in the same solution so they were using Project to Project references, so as one changed the others should have been updated. However it was not the case, I tried to build, rebuild, close VS2010, pulled a new copy from our source control. None of this worked, what I finally ended up trying was right clicking on the project and rebuilding each project individually. That updated the .dlls and .pdb files so I could debug through.
The issue here is that your dll and or your pdb files are not in sync.
Follow these steps
Just delete the bin directory from the project where the DLL is generated.
Re-build the project.
Remove reference from the project that make reference to the DLL.
Include again the reference.
Enjoy.
In addition to these answers I had the same issue while replacing new DLLs with old ones because of the wrong path. If you are still getting this error you may not refer the wrong path for the DLLs. Go to IIS manager and click the website which uses your DLLs. On the right window click Advanced Settings and go to path of the Physical Path folder on File Explorer and be sure that you are using this folder to replace your DLLs.
Some things for you to check:
Have you double checked your project references?
Do you have a Visual Studio started web server still running? Check the system tray and look for a page with a cog icon (you may have more than one):
(source: msdn.com)
Right click and close/exit it. You may have more than one. Can you debug your changes now?
Are you running the debug version but have only built the release version (or vice versa)?
Did the compile actually succeed? I know I've clicked through the "there were errors, do you want to continue anyway?" message a couple of times without realising.
With web services, the problem can be caused by using the Visual Studio "View in Browser" command. This places the service's DLL and PDB files in the bin and obj folders. When stepping into the web service from a client, somehow Visual Studio uses the PDB in the bin (or obj) folder, but it uses the DLL in the project's output build folder. There are a couple workarounds:
Try deleting the DLL and PDB files in the web service bin and obj files.
Try clicking "View in Browser" in Visual Studio.
If you previously got the source file mismatch error, Visual Studio might have added the filename to a black list. Check your solution properties. Choose "Common Properties -> Debug Source Files" on the left side of the dialog box. If your web service source files appear in the field "Do not look for these source files", delete them.
Unload the project that has the file that is causing the error.
Reload the project.
Fixed
I just had this issue.
I tried all the above, but only this worked:
delete the .pdb file for the solution.
delete the offending .obj files (for the file being reported out of sync)
build the solution.
This fixed the issue for all builds moving forward for me.
In Visual Studio 2017 deleting the hidden .vs folder in the resolved this issue for me.
This is how I fixed the problem in Visual Studio 2010:
1) Change the 'Solutions Configurations' option from "Debug" to "Release"
2) Start debugging
3) Stop debugging and switch the 'Solutions Configurations' option back to "Debug"
This worked for me. Step 3 is optional - it was working fine when I changed it to "Release" but I wanted to change it back.
My solution:
I had included an existing project from a different solution in a new solution file.
I did not notice that when the existing project was rebuilt, it was putting the final output into the NEW solution's output directory. I had a linker path defined to look into the OLD solution's output directory.
Switching my project to search in the new solution's output directory fixed this issue for me.
I had this problem, and it turns out I was running my console application as a windows application. Switching the output type back to console fixed the issue.
I had the same problem. To fix it I used the "Release Mode" to debug in VS2013. Which is sufficient for me, because I'm working in a node js\c++ addon.
My problem was that I had two projects in my solution. The second one was a test project used to call the first one. I had picked the path to the references from the bin folder's release folder.
So whenever I made a change to the first project's code and rebuilt it, it would update the dlls in the debug folder but the calling project was pointing to the release folder, giving me the error, "the source file is different from when the module was built."
Once I deleted the reference to the main project's dll in the release folder and set it to the dll in the debug folder, the issue went away.
In my case, the #Eliott's answer doesn't work.
To solve this problem I had Exclude/Include From Project my deficient file, andalso Clean and Rebuild the solution.
After these actions, my file with my last modifications and the debugger are restored.
I hope this help.
solution:-
the problem is:-
if your some projects in a solution , refer to some other projects,
then sometimes the dll of some projects, will not update automatically, whenever you build the solution,
some projects will have previous build dlls, not latest dlls
you have to go manually and copy the dll of latest build project into referenced project
I was using Visual Studio 2013 and I had an existing project under source control.
I had downloaded a fresh copy from source control to a new directory.
After making changes to the fresh copy, when building I received the error in question.
My solution:
1) Open Documents\IISExpress\config\applicationhost.config
2) Update virtualDirectory node with directory to the fresh copy and save.
My problem was that I had a webservice in the project and I changed the build path.
Restoring the default build path solved my issue.
I had this same problem and I followed the majority of the guidance in the other answers posted here, nothing seemed to work for me.
I eventually opened IIS and recycled the application pool for my web application. I have IIS version 8.5.9600, I right-clicked my web application, then: Deploy > Recycle > Recycle application pool > OK.
That seems to have fixed it, breakpoints now being hit as expected. I think that doing this along with deleting the bin and obj folders helped my situation.
Good luck!
I know this is an old question but I just had the same problem and wanted to post here in case it helps someone else. I got a new computer and the IT dept merged my old computer with the new one. When I set up TFS, I mapped a different local path than what I was previously using, to an additional internal drive. The old path still existed from the merged data on my hard drive so I could still build and run. My IIS paths were also pointing to the old directory. Once I updated IIS to the correct path, I was able to debug just fine. I also deleted the old directory for good measure.
I also experienced that. I just open the obj folder on the project and then open the debug folder delete the .pdb file and that's all.
This error also happens if you try to make changes to a source file that is not part of the project.
I was debugging a method from a .dll of another one of my projects, where Visual Studio had quite helpfully loaded the source because the .dll had been built on the same machine and it knew the path to the source. Obviously, changing such a file isn't going to do anything unless you rebuild the referenced project.
Delete all breakpoints.
Rebuild.
Done
At Visual Studio 2015, using C++, what fixed for me the the source file is different from when the module was built problem was
restart Visual Studio.
Check if the location you pointed to using mex() in Matlab is correct (contains lib and obj files which are modified to the last date you compiled the library in Visual studio).
If this is not the case:
Make sure you are compiling Visual studio in a mode that saves .lib files :
properties -> Config properties -> General -> Config type -> static library
properties -> Config properties -> General -> Target extension=.lib (instead of exe)
Make sure the output and intermediate directories match the Matlab directory in
properties -> Config properties -> General -> Output directory
properties -> Config properties -> General -> Intermediate directory
I get this issue when debugging sometimes w/ Visual Studio but when the application is served by IIS. (we have to develop in this form for some complicated reasons that have to do with how the original developer setup this project.)
When I change the file and rebuild, that fixes it a lot of the time. I know that sounds silly, but I was just trying to debug some code to see why it's doing something weird when I haven't changed it in a while, and I tried a dozen things from this page, but it was fixed just by changing the file..
In my case, the problem was that the debugger exe path was pointing to a net5.0 bin folder. I am using net6.0, so I should've updated the exe path back when I updated the target framework. Works fine now.
Debug-> start without debugging.
This option worked for me. Hope this helps!