Related
Really struggling with an issue publishing a Blazor WASM project that is using .NET 6.
Previously, it was on .NET 5, and there were no issues with building / publishing the app.
I've updated it to .NET 6, by essentially updating the nuget references for:
Microsoft.AspNetCore.Components.WebAssembly (to 6.0.0-rc.2.21480.10)
Microsoft.AspNetCore.Components.WebAssembly.DevServer (to 6.0.0-rc.2.21480.10)
We've updated to .NET 6 due to a requirement on DynamicComponent
Running locally during development is fine.
During our build pipeline, I am executing the following to publish the app:
dotnet publish .\Web\Web.Connect --configuration debug --output output
The output that I am getting is:
Web.Connect -> C:\git\core\Web\Web.Connect\bin\debug\net6.0\Web.Connect.dll
Web.Connect (Blazor output) -> C:\git\core\Web\Web.Connect\bin\debug\net6.0\wwwroot
Optimizing assemblies for size, which may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
C:\Program Files\dotnet\sdk\6.0.100-rc.2.21505.57\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(404,5): error : System.ArgumentException: An item with the same key has already been added. Key: C:\git\core\Web\Web.Connect\obj\debug\net6.0\build-gz\bxkpRzBw.gz [C:\git\core\Web\Web.Connect\Web.Connect.csproj]
C:\Program Files\dotnet\sdk\6.0.100-rc.2.21505.57\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(404,5): error : at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior) [C:\git\core\Web\Web.Connect\Web.Connect.csproj]
C:\Program Files\dotnet\sdk\6.0.100-rc.2.21505.57\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(404,5): error : at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value) [C:\git\core\Web\Web.Connect\Web.Connect.csproj]
C:\Program Files\dotnet\sdk\6.0.100-rc.2.21505.57\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(404,5): error : at Microsoft.NET.Sdk.BlazorWebAssembly.ComputeBlazorPublishAssets.GroupExistingStaticWebAssets(Dictionary`2 assemblyAssets, Dictionary`2 nativeAssets, Dictionary`2 satelliteAssemblyAssets, Dictionary`2 symbolAssets, Dictionary`2 compressedRepresentations) [C:\git\core\Web\Web.Connect\Web.Connect.csproj]
C:\Program Files\dotnet\sdk\6.0.100-rc.2.21505.57\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(404,5): error : at Microsoft.NET.Sdk.BlazorWebAssembly.ComputeBlazorPublishAssets.Execute() [C:\git\core\Web\Web.Connect\Web.Connect.csproj]
Ok - so some asset is trying to be published multiple times in ComputeBlazorPublishAssets?
Found information indicating that adding <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles> to the *.csproj might help here, but it has made no difference.
I have ensured that the wasm-tools have been installed via dotnet workload install wasm-tools.
Running a "Publish" via VS 2022 also gives the same error.
I am at a loss as to how I can debug this, or figure out what is getting generated twice, or how to fix this issue.
Thanks.
Ok,
After a significant amount of investigation looking at the binlog files, I have managed to track this down to the fact that my referenced library (which is a netstandard 2.0 project shared with other projects in the solution) was also outputting an app.config file (possibly due to an earlier time when we targeted both netstandard2.0 and net472).
Looking at the MSBuild bin logs:
So, there were two compressed files with the same name - one was referencing the actual *.dll, but the other was referencing *.dll.config
I deleted the app.config (it wasn't really needed and was probably there due to some historic reason) and it's now publishing as expected.
I built a complete Xamarin From application. When I change build mode to Release I get this error message:
Severity Code Description Project File Line Suppression State
Error The "LinkAssemblies" task failed unexpectedly.
Mono.Linker.MarkException: Error processing method: 'System.Void
Microsoft.Extensions.Primitives.InplaceStringBuilder::Append(System.String,System.Int32,System.Int32)'
in assembly: 'Microsoft.Extensions.Primitives.dll' --->
Mono.Cecil.ResolutionException: Failed to resolve System.Void
System.Runtime.CompilerServices.Unsafe::CopyBlockUnaligned(System.Void*,System.Void*,System.UInt32)
at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod(MethodReference
reference) at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference
reference) at
Mono.Linker.Steps.MarkStep.MarkInstruction(Instruction instruction)
at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body) at
Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method)
at Mono.Linker.Steps.MarkStep.ProcessQueue() --- End of inner
exception stack trace --- at
Mono.Linker.Steps.MarkStep.ProcessQueue() at
Mono.Linker.Steps.MarkStep.ProcessEntireQueue() at
Mono.Linker.Steps.MarkStep.Process() at
Mono.Linker.Steps.MarkStep.Process(LinkContext context) at
Mono.Linker.Pipeline.Process(LinkContext context) at
MonoDroid.Tuner.Linker.Process(LinkerOptions options, LinkContext&
context) at
Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver
res) at Xamarin.Android.Tasks.LinkAssemblies.Execute() at
Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at
Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext() EClinicForDoctor.Android
After searching on the Internet, I find this solution which says:
The resolution to this issue is to make sure you have the latest supported Android SDK versions, and set the Target Framework to Use latest installed platform. It's also recommended that you set the Target Android Version to Use Target Framework Version and the minimum Android version to API 15 or higher. This is considered the supported configuration.
Thus I update Android SDKs, set Target Framework and set minimum Android version to API 15.
However, I still get the same error. Another solution says that I should update NuGet Packages. I found that the version of the package System.Runtime.CompilerServices.Unsafe is 4.3.0 and there is an update for this package. When updating the package, the error no longer appear but another problem occur. When the app deployed, it run and stop without any error message. The mobile just exit from application without showing any error message. This happens when the package System.Runtime.CompilerServices.Unsafe is on version higher than 4.3.0. I tried to remove the package and the same problem happens again. How can I solve this problem?
I've seen this issue popup at a few different locations now. There is some discussion going around it like here: https://github.com/xamarin/xamarin-android/issues/1196
This Github issue also lists some (possible) solutions, the one with the most positive feedback seems to be this one:
Here's a functioning workaround. It's hacky and ugly but works with
minimum fuss. Put this in an XML file and <Import> it in your Android
csproj file at the end. It works at least for System.Buffers
<!-- Workaround for https://github.com/xamarin/xamarin-android/issues/1162 -->
<Project>
<Target Name="ReplaceRefAssemblies" AfterTargets="_ResolveAssemblies">
<ItemGroup>
<ResolvedAssembliesFixedWindows Include="#(ResolvedAssemblies->Replace('\ref\','\lib\'))" />
<ResolvedAssembliesFixedUnix Include="#(ResolvedAssemblies->Replace('/ref/','/lib/'))" />
<ResolvedAssembliesFixed Include="#(ResolvedAssembliesFixedWindows)" Condition="#(ResolvedAssembliesFixedWindows) != #(ResolvedAssemblies)" />
<ResolvedAssembliesFixed Include="#(ResolvedAssembliesFixedUnix)" Condition="#(ResolvedAssembliesFixedUnix) != #(ResolvedAssemblies)" />
<ResolvedAssemblies Remove="#(ResolvedAssemblies)" />
<ResolvedAssemblies Include="#(ResolvedAssembliesFixed)" />
</ItemGroup>
</Target>
</Project>
Another uses the XML from above and says:
I've just copied the content from the link above and saved as UnsafeFix.xml file in the Android project folder.
Then just added: <Import Project="UnsafeFix.xml" /> at the end of android .csproj file, just before
Cleared everything, recompiled and it finally worked!
Finally I get the solution. One of the comments in the issue provided by #Gerald Versluis solve the problem:
I follow these steps of hongliyu2002
https://forums.realm.io/t/could-not-load-assembly-system-runtime-compilerservices-unsafe-during-startup-registration/974/4
Go to C:\Users%user%.nuget\system.runtime.compilerservices.unsafe\4.4.0, and
delete "ref" folder then make a copy of "lib" folder and rename the
copy back to "ref".
Cleanup all the "bin" and "obj" folders in the projects.
Rebuild and run..
This simple workaround , works for me :) My current version is
Xamarin.Forms 2.5.1.444934
I'm pretty new to CI (from a brand new set up point at least). I created a project in Rider, using the default version of NUnit that is provided if you select to 'Create new NUnit Project', and I am now trying to set up an automated build for it using travis-CI.
The target .NET framework version of my project and test projects (confirmed in Project properties in Rider) is 4.5.
The version of Nunit I am using is the default version provided with Rider, 3.5.
Here is my .travis.yml build file:
language: csharp
solution: .sln
install:
- nuget restore FindWordsWithConcatenations.sln
- nuget install NUnit.Runners -Version 3.5.0 -OutputDirectory testrunner
script:
- xbuild /p:Configuration=Debug ./FindWordsWithConcatenations.sln
- mono ./testrunner/NUnit.ConsoleRunner.3.5.0/tools/nunit-agent.exe ./TestFindWordsWithConcatenations/bin/Debug/TestFindWordsWithConcatenations.dll
I confirmed on my own machine by running the nuget command that the test runner path should be correct, when I run the nunit-agent (via agent, agent-x86, or agent-console) I get the following error (locally, and on the server):
Unhandled Exception: System.FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
at System.Guid..ctor(String g)
at NUnit.Agent.NUnitTestAgent.Main(String[] args)
I've also tried running with no configuration mode specified, and with configuration mode of Debug and Release specified.
Unfortunately, the normal tactic of googling/stack overflow hasn't helped, I've seen this error in a few questions, but the cause never seems related to what I'm experiencing.
The last build of the pipeline is available to view here, all the builds thus far have failed, previous builds can be seen here.
Thanks in advance, I would be very grateful if someone had any idea about the cause of this issue, or how I could tackle the test running in a different way.
Solved it.
Updated the script section of the travis config to:
script:
- xbuild /p:Configuration=Debug ./FindWordsWithConcatenations.sln
- mono ./testrunner/NUnit.ConsoleRunner.3.5.0/tools/nunit3-console.exe ./TestFindWordsWithConcatenations/bin/Debug/TestFindWordsWithConcatenations.dll
So it's now running the correct console application. Also had to modify the test paths a bit for it to run on the server.
I have a simple .NET Core project (console app) that I'm trying to compile and run. dotnet build succeeds, but I get the following error when I do dotnet run:
dotnet run
Project RazorPrecompiler (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in [path].
My project.json looks like this:
{
"buildOptions": {
"warningsAsErrors": true
},
"dependencies": {
"Microsoft.AspNetCore.Razor": "1.0.0",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
},
"description": "Precompiles Razor views.",
"frameworks": {
"netcoreapp1.0": {
"imports": [ ]
}
},
"version": "1.2.0"
}
What is hostpolicy.dll, and why is it missing?
Update for dotnet core 2.0 and beyond: the file appname.runtimeconfig.json (for both debug and release configuration) is needed in the same path as appname.dll.
It contains:
{
"runtimeOptions": {
"tfm": "netcoreapp2.0",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "2.0.0"
}
}
}
then dotnet.exe exec "path/to/appname.dll" [appargs] works.
This error message is unhelpful. The actual problem is a missing emitEntryPoint property:
"buildOptions": {
...
"emitEntryPoint": true
},
Once this is added, the compiler will let you know about any other problems (like a missing static void Main() method). Successfully compiling the project will result in an output that dotnet run can execute.
If I'm not mistaken, one scenario when you can hit the issue is this: You have an integration project that references another application project (not library). In this case, dependentProject.runtimeconfig.json won't be copied to your integration project's output folder and you won't be able to run dependentProject.exe binary because it will throw The library hostpolicy.dll was not found..
There is a Github issue for this and a workaround.
Edit: Should be fixed in .NET SDK 5.0.200.
I had similar problem running tests in VS19.
========== Starting test run ==========
Testhost process exited with error: A fatal error was encountered. The
library 'hostpolicy.dll' required to execute the application was not
found in 'C:\Program Files\dotnet'. Failed to run as a self-contained
app.
After digging into it I found the source of the problem:
The full path the the .runtimeconfig.json in the test binary folder was above 255 characters. Renaming the module, so the file path becomes shorter, resolved the problem.
This occurred when a Visual Studio 2019 preview upgrade .Net Core to the latest preview (specifically .Net Core 3.1.100-preview2-014569).
Reinstalling/repairing .Net Core 3.0.100 solved the problem for me.
I'm not sure why but I ran in to the problem when executing the .exe file in my \bin folder while the .exe in my \obj folder works fine.
I am having this problem in Dotnet Core 3.1 Console application.
If you are publishing your application, make sure that your target runtime set to the specific runtime that you had installed in your target machine.
If you set to portable it will pick whatever runtime that it feels comfortable (which you might not have it installed)
I had this happen with .NET 6.0 where somehow the appname.runtimeconfig.dev.json file was not being generated in the bin/Debug/net6.0/ directory.
The fix was modifying the .csproj file and include this fragment inside the <PropertyGroup> element:
<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>
I found this solution while searching with https://www.google.com/search?q=net60+runtimeconfig.dev.json at Breaking change: runtimeconfig.dev.json file not generated - .NET | Microsoft Learn with the solution at MSBuild properties for Microsoft.NET.Sdk - .NET | Microsoft Learn:
GenerateRuntimeConfigDevFile
Starting with the .NET 6 SDK, the [Appname].runtimesettings.dev.json file is no longer generated by default at compile time. If you still want this file to be generated, set the GenerateRuntimeConfigDevFile property to true.
<PropertyGroup>
<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>
</PropertyGroup>
After applying this to the .csproj file and re-building the project, debugging from Visual Studio Code worked fine including stopping at the breakpoints that I had set previously.
For me the issue was with the version mismatch. I had a different ".Net core SDK" version installed and a different version was specified in .json file.
Once I modified the version in my .json file the application started working fine.
In my case it was because I was publishing a self-contained application for the wrong target. My intent was to run on alpine linux, but I was building for libc when I should have been building for musl.
The failing package was built using:
dotnet publish --self-contained true --runtime linux-x64 --framework netcoreapp2.1 --output /app
Changing the RID:
dotnet publish --self-contained true --runtime linux-musl-x64 --framework netcoreapp2.1 --output /app
produced a functional package. Notice the RID changed from linux-x64 to linux-musl-x64. If I had read the .NET Core RID Catalog page this could have been avoided. 😅
Maybe you didn't want to do a "Console .Net Core" project but a "Console .Net Framework" project. It solves the problem, for me...
My problem was that I have 2 .NET Core App projects and one is dependent on the other.
(so I can then execute that application from that other application)
But .NET Core applications (with default config) need <assembly name>.runtimeconfig.json file (to get some launch config) which isn't copied by default.
The only solution that worked for me was adding to Project Properties > Build Events (of the dependent project) this command:
COPY "$(SolutionDir)<dependency name>\$(OutDir)<dependency assymbly name>.runtimeconfig.json" "$(SolutionDir)$(ProjectName)\$(OutDir)" /Y
But you can also copy the <dependency assembly name>.runtimeconfig.json file by hand to the dependent project.
Note that there should be a better more generic way to do this for every .NET Core App Project automatically.
This error is quite generic. So the real problem can be anything.
In my case (if helps anyone with same issue), I created a Class Library project instead of a Console Application project.
A Class Library DLL can't be runned with MSBuild, even if it has a Main method.
Only Console Application DDL can be runned as dotnet <appname>.dll
I was getting similar error while running Unit tests using VSTest#2 task in Azure Devops.
In my case, the problem was with my testAssemblyVer2 value. I was giving wrong pattern for test dlls.
Below one worked for me.(if you are getting this error with VSTest)
- task: VSTest#2
displayName: 'Running UnitTests'
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
$(System.DefaultWorkingDirectory)\SrcFolder\BBBB.UnitTests\**\bin\**\*.BBBB.UnitTests.dll
$(System.DefaultWorkingDirectory)\SrcFolder\AAAAa.UnitTests\**\bin\**\*.AAAA.UnitTests.dll
!**\*TestAdapter.dll
!**\obj\**
platform: x64
configuration: Debug
codeCoverageEnabled: true
So try to give correct pattern value for testAssemblyVer2 input. Make sure its filtering only the required dlls.
I had this same problem with a .NET Core 3.0 WPF app, but I found that my app wouldn't run in Visual Studio 2019 either.
I discovered on the project properties page (right-click on project > Properties) that the Target framework was set to .NET Core 3.0.
I'd recently updated VS 2019 which had also installed .NET Core 3.1, so I switched to that in the dropdown, and it worked again.
(I also had to update my shortcut to point to the netcoreapp3.1 folder instead of the previous netcoreapp3.0 folder.)
Promoting voltrevo's comment as an answer as I believe this should be the most common case of the problem. When you build your solution, sometimes you might get 2 directories with outputs bin and obj. 'Bin' directory has everything that is needed to run dotnet.exe command. Just run from the bin directory and things should be good. :)
For me with ASP.NET Core 2.0 on Azure, it was the appname.deps.json that did the trick. You need to copy it from your build directory to Azure.
For me, the error occurred during the SonarQube coverage scan due to one of the projects had a project reference to a MSTest project.
I faced this problem and it took me couple of days to figure out the solution.
Go to Visual Studio Installer.
Click on 'More' option of the Visual Studio.
Select 'Repair'.
It'll take some time for the download and installation.
Once it's completed restart the machine and try again.
This should solve the issue.
Add the OutputType on the PropertyGroup and issue is solved
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
more about this MSBuild can be found here
I'm trying to deploy a ClickOnce application, but installation fails on the client. Here's the error log:
PLATFORM VERSION INFO
Windows : 6.1.7601.65536 (Win32NT)
Common Language Runtime : 4.0.30319.1
System.Deployment.dll : 4.0.30319.1 (RTMRel.030319-0100)
clr.dll : 4.0.30319.1 (RTMRel.030319-0100)
dfdll.dll : 4.0.30319.1 (RTMRel.030319-0100)
dfshim.dll : 4.0.31106.0 (Main.031106-0000)
SOURCES
Deployment url : http://MyProduct.com/download/workstation/MyProduct%20Front%20Desk.application
Server : Microsoft-IIS/7.5
X-Powered-By : ASP.NET
Deployment Provider url : http://MyProduct.com/Download/Workstation/MyProduct%20Front%20Desk.application
Server : Microsoft-IIS/7.5
X-Powered-By : ASP.NET
Application url : http://MyProduct.com/Download/Workstation/Application%20Files/MyProduct%20Front%20Desk_1_0_0_7/MyProduct%20Front%20Desk.exe.manifest
Server : Microsoft-IIS/7.5
X-Powered-By : ASP.NET
IDENTITIES
Deployment Identity : MyProduct Front Desk.application, Version=1.0.0.7, Culture=neutral, PublicKeyToken=df343a0868ab2d74, processorArchitecture=msil
Application Identity : MyProduct Front Desk.exe, Version=1.0.0.7, Culture=neutral, PublicKeyToken=df343a0868ab2d74, processorArchitecture=msil, type=win32
APPLICATION SUMMARY
* Installable application.
ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* Activation of http://MyProduct.com/download/workstation/MyProduct%20Front%20Desk.application resulted in exception. Following failure messages were detected:
+ Reference in the manifest does not match the identity of the downloaded assembly MyProductSiteServer.exe.
COMPONENT STORE TRANSACTION FAILURE SUMMARY
No transaction error was detected.
WARNINGS
There were no warnings during this operation.
OPERATION PROGRESS STATUS
* [03/17/11 11:51:04] : Activation of http://MyProduct.com/download/workstation/MyProduct%20Front%20Desk.application has started.
* [03/17/11 11:51:04] : Processing of deployment manifest has successfully completed.
* [03/17/11 11:51:04] : Installation of the application has started.
* [03/17/11 11:51:05] : Processing of application manifest has successfully completed.
* [03/17/11 11:51:06] : Found compatible runtime version 4.0.30319.
* [03/17/11 11:51:06] : Request of trust and detection of platform is complete.
ERROR DETAILS
Following errors were detected during this operation.
* [03/17/11 11:51:30] System.Deployment.Application.InvalidDeploymentException (RefDefValidation)
- Reference in the manifest does not match the identity of the downloaded assembly MyProductSiteServer.exe.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.DownloadManager.ProcessDownloadedFile(Object sender, DownloadEventArgs e)
at System.Deployment.Application.FileDownloader.DownloadModifiedEventHandler.Invoke(Object sender, DownloadEventArgs e)
at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem next)
at System.Deployment.Application.SystemNetDownloader.DownloadAllFiles()
at System.Deployment.Application.FileDownloader.Download(SubscriptionState subState)
at System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState subState, AssemblyManifest deployManifest, AssemblyManifest appManifest, Uri sourceUriBase, String targetDirectory, String group, IDownloadNotification notification, DownloadOptions options)
at System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState subState, ActivationDescription actDesc, Int64 transactionId, TempDirectory& downloadTemp)
at System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState& subState, ActivationDescription actDesc)
at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)
COMPONENT STORE TRANSACTION DETAILS
No transaction information is available.
The main exe I need to deploy is MyProductFrontDesk.exe, which has a dependency on MyProductSiteServer.exe - and that appears to be where the error is being thrown: "Reference in the manifest does not match the identity of the downloaded assembly MyProductSiteServer.exe."
Which manifest needs to be corrected? And how?
There was an issue with Visual Studio 2008 which is solved by not embedding the default manifest - one of the comments on that article suggests the problem still exists in Visual Studio 2010.
In project properties -> Application tab -> Resources -> checkbox Icon and manifest, the setting "Embed manifest with default settings" caused the problem. Setting it to "Create application without a manifest" fixes the problem.
I had the same issue when I added a reference to another project.
The way to solve this was enabling ClickOnce Security Settings in all referenced projects as Ian explained here (emphasis mine):
For me, the way this was resolved was to ensure that all the Projects under the Solution which exposed the "Security Tab" in their "Project Properties" had the Option "Enable ClickOnce Security Settings" Ticked with the Option "This is a full trust application" Selected. This has to do with creating the Manifest correctly and the application will not install if these options are not set on all the Projects within the Solution that require it.
I believe this is the proper way to fix it when making a reference to another project under the same solution.
The linked forum post has expired by now, but it's available on archive here.
I was encountering the same problem, but my solution was very different.
My ClickOnce application was referencing another EXE file project in my solution, so when the client downloaded it, and there was another EXE file, that one didn't have a manifest.
Removing the dependency on another executable solved my problem.
I confirmed that the issue also exists in Visual Studio 2010. Selecting "Create application without a manifest" in Project Properties - Application - Resources solved the problem.
I have experienced the same error when deploying with the project set to Debug. When it was changed back to Release there was no error.
This can also happen if you have two different versions of a NuGet package referenced in different DLL files in your project. In my case I was using a framework called Catel, and I had a newer version referenced in one DLL file than another (oversight), but this caused ClickOnce to spit out this error. Referencing the same version resolved the problem.
I had the same problem, but my solution was to change the 'Platform target' to 'x86' (Project Properties -> Build Tab). It was set to Any CPU. As soon as I changed the setting and republished, the ClickOnce installer was able to complete.
I had exactly the same issue. I could not remove the dependency as it was needed by the main project. The second project was a console project.
I changed to Class Library, and then it all worked.
I had the same issue, and I tried all of previous suggested solutions here, and all of them didn't work.
I fixed it by changing the update location. From project properties -> Publish -> Updates. Change the update location to your published folder.
Another workaround, in case the dependency exe with the bad app manifest cannot be changed (say coming from a NuGet package). The binary can be included as content with a dummy extension so ClickOnce does not try validating the manifest and then renamed during app startup.
csproj:
<Content Include="..\packages\<package>\lib\<app>.exe">
<Link><app>.exe.bin</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
<ItemGroup>
<PublishFile Include="<app>">
<Visible>False</Visible>
<Group>
</Group>
<TargetPath>
</TargetPath>
<PublishState>Exclude</PublishState>
<IncludeHash>True</IncludeHash>
<FileType>Assembly</FileType>
</PublishFile>
</ItemGroup>
App.xaml.cs:
public partial class App : Application
{
private void Application_Startup(object sender, StartupEventArgs e)
{
var appDir = Path.GetDirectoryName(Process.GetCurrentProcess().MainModule.FileName);
if (!File.Exists($"{appDir}\\<app>.exe"))
{
File.Copy($"{appDir}\\<app>.exe.bin", $"{appDir}\\<app>.exe");
}
}
}
If you have one main program that references another then you have to do the "Create application without a manifest" trick on the main program's Program:
Project --> Properties --> Application Tab -->Resources --> Manifest -->drop down "Create application without a manifest"
and then switch over to the referenced program's Project Properties and repeat the process.
I had the same issue a couple of minutes ago, and below are the steps that I used to solve it.
Key
a = Main project (the project you want to publish, e.g. myProduct)
b = Reference project (e.g. MyProductSiteServer)
Checklist
Navigate to properties -> Application -> Resources -> check icons and manifest (for both a and b)
Navigate to properties -> Build : make sure that a and b are on the same target platform
Navigate to properties -> Security and make sure that a and b have these settings checked: "Enable ClickOnce security settings" and "This is a full trust application"
Navigate to properties -> Publish : I recommend you change the path of the publishing folder
ALSO SOLVED FOR ClickOnce .exe calling .exe calling .exe.
I had this problem also, using VB.NET in Visual Studio 2010.
I have a ClickOnce Windows Forms application that references a second Windows Forms application that in turn references a third Windows Forms application. (These second and third applications are EXE files rather than DLL file for simplicity, as they are equally likely to be run stand-alone or called with properties passed to them.)
I had to comment out BOTH the second and third applications' manifest contents per:
Walkthrough: Manually Deploying a ClickOnce Application
It works perfectly.
I use mage.exe to generate my manifest. Adding this to my .csproj fixed the issue. You may also try the -nowin32manifest compiler flag; I've not tested it. I don't see stuartd's "Create application without a manifest" in Visual Studio 2017; I think this is what it does though.
<PropertyGroup>
<NoWin32Manifest>true</NoWin32Manifest>
</PropertyGroup>
I also have this in my .csproj:
<GenerateManifests>false</GenerateManifests>
I had this exact same issue with my VS 2019 application.
I have tried creating the application without a manifest however that did not work.
What did work however was the following:
Go to Build-->Publish-->Application
Click on the "Assembly Information" button
Tick the "Make assembly COM-Visible" option
Hopefully, this helps!
it seems like the issue is caused by the setup.exe in vs 2019. it seems that the exe won't update its version when doing a new deployment. the workaround for me is to
delete everything in the deployment folder.
uncheck "Create setup program to install prerequisite components" in Properties => Publish => Prerequisite.
do a deployment.
come back and re-enable "Create setup program to install prerequisite components".
guess this process will force vs 2019 to update setup.exe to the correct version.
also Project --> Properties --> Application Tab -->Resources --> Manifest -->drop down "Create application without a manifest" will work but the app won't update if there is a newer version so I have to fall back to the workaround above.
I faced the same, So whenever you update an assembly , In my case I was downgrading from CR For .Net framework 4.0 to Framework 2.0 , I replaced all referenced assemblies with the old one , The project runs fine but in order to publish
YOU MUST CLEAN WHOLE SOLUTION
then rebuild all , then publish it will solve the problem.
Thanks
I am using Visual Studio 2012 on Windows 7 and need to publish a solution consisting of two projects.
As Eduardo pointed out, marking both projects as ClickOnce, and enabling Full Trust Application resolves the problem.
I had a bit of a different problem that I was able to resolve and so I wanted to post. My issues was I was running 3 branches out of TFS. I had upgraded Telerik controls in one of my branches but not the others. Once I upgraded the Telerik controls in all 3 branches and re-published it worked and this error went away.
I was running VS2015 at the time.
It is interesting. I just redeploy the application and problem solved. Maybe a file corruption because of network.
In my version of Visual Studio 2017, version 15.6.6 (but it may been have there earlier) I found that the Application Files was not in the Right Click Exe Project and Publish, but under the Project Properties Publish Tab where you can set which of the Application Files that you want to to be put in the install.
So take out the ones that are a problem. If something is already installed on a computer where this app will be installed, there is no reason to try to reinstall it anyways, except if you need the reference for it to run. If it were to install what was already on the pc, but to a different folder it might not work. It is best to use the other applications or dll assemblies to the same location as they were previously installed.
In my case 2 exe projects in a solution had .NET target set to 4.8 and 4.6.1. After I set both to 4.8, the error stopped.
I am Using Visual Studio 2022 and the error came up.
Solved it by excluding Log4Net file in the Publish > Application Files.
and the error Stopped