I was trying to run one of my apps after a fresh windows installation, and then I get this message in Visual Studio:
Severity Code Description Project File Line Suppression State
Error DEP0700: Registration of the app failed. [0x80073CF3] Windows cannot install package 464|APPPUBLISHER|.|APPNAME|_1.7.0.0_x86__yejd587sfa94t because this package depends on a framework that could not be found. Provide the framework "Microsoft.UI.Xaml.2.1" published by "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x86 processor architecture and minimum version 2.11904.5004.0, along with this package to install. The frameworks with name "Microsoft.UI.Xaml.2.1" currently installed are: {} |APPNAME|
And here is a screenshot (The app name and publisher are hidden):
Does anybody know a solution for this?
Also, in a desperate case, if I publish a recreation of this app in the Microsoft Store, will it install properly?
Edit: it seems like every time I change the version of the app, the package that won't install synchronizes with the changes
Edit 2: Is there any way to download this package from NuGet or restore it to the app package?
Edit 3: This app was always a big problem and never behaved as it should. This isn't the first time I'm having similar problems
Have you tried to right click on references, Select Manage NuGet Packages and searched for that package?
I found a solution to this problem and, actually, the only solution. Since this app had a history of API problems, I decided to make a new one with the exact same properties, but with some fresh NuGet packages. This solved the issue and improved the performance a lot. Now, I don't have to worry about it failing to load every time I reinstall Windows since it was the only app that caused problems.
The package that this app was asking for was a cache that I couldn't get rid of, and was stuck in the files as a dependency on something that doesn't even exist.
Related
I'm attempting to set myself up with Azure Data Studio on my new M1 Mac Mini, but the SQL Server database project I'm working on refuses to build. This is the (completely useless) error I'm getting:
stdout: /Users/dumasded/.azuredatastudio/extensions/microsoft.sql-database-projects-0.13.0/BuildDirectory/Microsoft.Data.Tools.Schema.SqlTasks.targets(586,5): error MSB4181: The "SqlBuildTask" task returned false but did not log an error. [/Users/dumasded/Projects/db-project/DBProject.sqlproj]
stdout: 0 Warning(s)
stdout: 1 Error(s)
I can neither find nor remember where I got this idea but I somehow got it into my head that this has something to do with the version of the SDK I'm using - I'm currently using 6.0.100, which as far as I can tell is the only one that's arm64 compatible. Every attempt I've made to download, install and run an earlier version of the SDK on this machine has failed. If that is in fact the problem, I can't even get far enough to find out.
Just to be sure it wasn't something to do with the existing project I was trying to set up, I created a brand new one from scratch and attempted to build that. It failed with the same error. It definitely appears to be a system issue and not a project-specific one.
Is there any hope for me? Am I doomed to return to working on my crummy Lenovo Thinkpad? My breath is bated. Thanks in advance.
EDIT
I've just come across the ingenious MSBuild.Sdk.SqlProj as a potential solution to my issue, however my attempts to use it are still running up against SDK version issues:
error : The current SDK bundles target framework 'netcoreapp6.0' which is not supported by MSBuild.Sdk.SqlProj. Either install a .NET Core SDK that supports 2.1, 3.1 or 5.0, or file an issue at https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/ to add support.
This would seem to confirm my initial suspicion that this is an issue of SDK versions.
EDIT 2
Neglected to mention that I'm using Azure Data Studio with the SQL Database Projects extension, which purports to handle the DACPAC creation seamlessly and across platforms. Though that hasn't been my experience thus far.
I'll be dunked. I knew there had to be a deceptively simple answer to this.
It turns out that my attempts to download, install and run an earlier version of the SDK on my machine weren't failing - they were just going into a different directory. Apparently, installing x64 SDKs on an arm64 machine results in the SDKs being created in a dedicated 'x64' subdirectory of the primary dotnet installation. This is painfully obvious to me now - the reason dotnet --list-sdks showed no trace of the earlier SDKs was that they were being installed for a completely isolated instance of dotnet. All I had to do was point the SQL Database Projects extension to that instance of dotnet and it started working:
I hope my publicly blundering my way through the maze of dotnet SDK architectures manages to help someone else. For my part I'm just so relieved I've finally gotten it to work.
I have written a Xamarin.Forms application and now I want to deploy the UWP project to the store but I can't create app packages.
When using Microsoft.NetCore.UniversalWindowsPlatform 6.2.2 or 6.2.0-preview I
in release mode, I constantly get this error :
Payload contains two or more files with the same destination path 'System.Runtime.CompilerServices.Unsafe.dll'. Source files:
C:\Users\john.nuget\packages\runtime.win10-x86-aot.microsoft.netcore.universalwindowsplatform\6.2.0-preview1-26926-04\runtimes\win10-x86-aot\lib\uap10.0.15138\System.Runtime.CompilerServices.Unsafe.dll
C:\Users\john.nuget\packages\system.runtime.compilerservices.unsafe\4.5.0\lib\netstandard2.0\System.Runtime.CompilerServices.Unsafe.dll OfflineCurrencyConverter.UWP
But I followed the answer to this GitHub issue saying I should downgrade the package to 6.1.9.
Doing this causes my application to build for ever... the build never stops.
But when I disable .NET Native Tool chain, it builds and run in release mode but packages can't still be created. Please does anyone have a solution ? I'm frustrated.
I feel wasted building a whole app and realizing it can't be packaged at the end for this UWP project.
If it took way longer than you expected to build in release mode, use nuget version of .net native by installing Microsoft.Net.Native.Compiler package on nuget in your project and re-build it as usual. This solution solves the very same problem you have now in my experience.
Building app for .NET Native in release mode can take a very long time. It can even take as much as 10 minutes for larger apps. So make sure to give the compiler the time it needs. It might seem it is building forever, but it should definitely finish.
I've created a pretty simple app that uses banner ads.
App works great with debuging mode with ads test ads showing up. But when I'm creating a appxupload and uploading it to store I'm getting error.
Your package Microsoft.Advertising.Xaml specifies version 10.1707.2.0, but 10.0.0.0 is the minimum available version.
What exactly is the problem, why package is getting rejected and how can it be resolved?
According to the description of the error, you have installed Microsoft.Advertising.Xaml package which can't work on the Windows version below 10.1707.2.0 (which hasn't even been released to the general public). Your app declares that it can work on every version of Windows 10. This is in a collision.
Had the EXACT same problem. Finally got mine to work by uninstalling the MSI from https://marketplace.visualstudio.com/items?itemName=AdMediator.MicrosoftAdvertisingSDK and installing the Microsoft.Advertising.XAML from NUGET package manager. It was only 1 version earlier, but let me publish my app to the store.
I am helping out with a project that a contractor worked on previously (so I don't have a lot of history for it).
The project builds fine, but when we try to perform some operations, we get a runtime error indicating that System.Management.Automation.dll could not be found.
As a troublshooting measure, we manually installed the dll into the installation directory. We then get an error indicating failure to load Microsoft.Management.Infrastructure.
As nearly as I can tell, these dlls are present in the Microsoft Management Framework download, and possibly in Powershell 3.0.
My question: What is the smallest package that these dlls are a part of, and what is the best way to deploy them for a production software release?
Edit
Just to be clear -- I am not looking to hack/frankenbuild by deploying just those dlls "naked", I am trying to identify the correct redistributable package for those dlls. I just can't seem to work out which one it is.
Edit
If it helps, the nature of the code that we are running is to programmatically create an exchange mailbox.
I think you can't legally redistribute any of those two DLLs alone (discussed for example here for the Automation, you can also check the "Redistributable" section on MSDN for those namespaces). You will have to make sure the target machines have PowerShell and the Management Framework.
Just in case anyone else runs into this problem: We ended up resolving the issue by deploying the Windows Management Framework 3.0, which includes the necessary assemblies. http://www.microsoft.com/en-us/download/details.aspx?id=34595
I would like to know if there is an easier way to install or uninstall windows services onto dev or test environments without creating setup packages? I am having issues with uninstalling visual studio packages sometimes (even after stopping the service and closing the service management console before uninstall forcing me to reboot the machine). this issue can be overcome by using tools like InstallShield or WIX to create setup packages, but during development it will be easier if I can install the service (along with all the dependent files) in dev or test environment without creating a setup package.
Use installutil, which is part of the .net framework. Now you still need to copy the bin directory to the desired machine and register any COM objects if you are using any.
If remember right,( no access to my dev machine at the moment). Stop the service - and replace the exes and dlls) restart the service. You can script this. You will need to do an initial install, or use the installutil.exe
I found this much easier that installing and uninstalling, all the time.
I find the SC.EXE command to be easy to use during development. Slap it into a NAnt/BuildBuild/Perl/BAT file and instant light weight automation.
I know this is an old question, but I feel this information is highly relevant to anyone struggling with this issue:
The problem comes from a change in the Installer included in Visual Studio. I think the change occurred between VS2005 and VS2008. Regardless, after the change, to have an update installer work properly without uninstalling the prior product, it was recommended that Services be installed via Custom Actions in the Install, Commit, and Rollback phase, but not the Uninstall phase. I believe this is because the change caused the Uninstall action to occur after the new version was installed, uninstalling your service upon update. A Condition of "Not PREVIOUSVERSIONSINSTALLED" is placed on the 3 Custom Actions and Check For Previous Versions must be TRUE. This results in essentially the same result as copying the files over the old ones (but also retains any other install activity such as registering objects, etc.)
This all works great for updates; a new version will install over an existing version, the service remains registered, all is well. However, if you uninstall, your service is left registered, and a fresh install will attempt to register it again, resulting in the 1001 error. I use SC.EXE to delete the service manually when I uninstall to avoid this. You can have a clean uninstall, but it will break update installs, your choice.