I've been trying to publish a WPF application I've been working on to a specific folder using Microsoft Clickonce. In my application I use the OpenCV wrapper EmguCV. However, when I publish the application and download and install it on a new machine, it gets thrown the following error.
Application: Photo.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.DllNotFoundException
at Emgu.CV.CvInvoke.RedirectError(CvErrorCallback, IntPtr, IntPtr)
at Emgu.CV.CvInvoke..cctor()
Exception Info: System.TypeInitializationException
at Emgu.CV.CvInvoke.cvCreateImageHeader(System.Drawing.Size, Emgu.CV.CvEnum.IplDepth, Int32)
at Emgu.CV.Image`2[[Emgu.CV.Structure.Gray, Emgu.CV, Version=4.6.0.5131, Culture=neutral, PublicKeyToken=7281126722ab4438],[System.Byte, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].AllocateData(Int32, Int32, Int32)
Whats really confusing me though is if I download my bin folder to that same machine and run the application, it works completely fine. Because of this I know the machine is not missing any runtimes, so it would have to be with Clickonce itself. I've verified that I'm targeting x64, and have also checked that all of the EmguCV dll's are being included in the Application Files section of Clickonce. I've also checked EmguCV's documentation about the issue and I've also verified that I have the correct Nuget package with the Emgu.CV.runtime.windows package.
Related
I have a Windows Console application that accesses our SQL database. This app works fine from VS2019, the debug folder and the release folder. However, if I publish this app, the installed version fails with the exception shown below.
I do note the following differences between the installed location (\AppData\Local\2.0\xxx\yyy) and the \Release folder:
The \Release folder has SNI files in the \x86 and \64 directories, but the installed directory is missing this information. How do I include this in the manifest? I suspect that this is the main issue causing the exception.
The manifest file in the installed location is missing information related to Identity - not sure if this is a concern, but perhaps it is?
Application: SmartRView Configuration.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ComponentModel.Win32Exception
at Microsoft.Data.SqlClient.SNINativeMethodWrapper..cctor()
Exception Info: System.TypeInitializationException
at Microsoft.Data.SqlClient.SNINativeMethodWrapper.SNIInitialize()
at Microsoft.Data.SqlClient.SNILoadHandle..ctor()
at Microsoft.Data.SqlClient.SNILoadHandle..cctor()
Exception Info: System.TypeInitializationException
at Microsoft.Data.SqlClient.TdsParser..cctor()
My local install of VS2019 (16) seems to be missing references to BrowserLink. I've tried repairing the installation, and installing multiple different SDK's to no avail.
Where is BrowserLink normally located? And what is the mechanism that causes it to be loaded in development versions? It doesn't seem to be packaged seperately from VS since version 12, unless you are using the new .net core versions.
We have checked the GAC, NuGET, and are running out of options.
It's a .net 4.5 project, if that's relevent.
Could not locate assembly Microsoft.WebTools.BrowserLink.Runtime, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a in the Assembly Stores configured. Requesting assembly:
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Exception: Could not locate assembly Microsoft.WebTools.BrowserLink.Runtime, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a in the Assembly Stores configured. Requesting assembly:
The root cause is almost certainly something to do with the dumb way this project has a shared non-standard assembly cache, and doesn't fallback to normal dev locations, but the question is about what the normal location/mechanism is for BrowserLink (16) to be loaded.
If you have installed your VS2019 in default options, you can find the Browser Link library files in this path:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\Extensions\Microsoft\Web Tools\Browser Link
(Replace the path of your installation location as appropriate)
You can then decide whether to copy Microsoft.WebTools.BrowserLink.*.dll to the assembly cache of your application or include this path in your application.
So let me start from the top. I have made a console app that will run daily with the use of a scheduled task. The console app works and has been tested. My issue is when I take the .exe and .exe.config from the bin I am moving these to a separate server changing the config to contain relevant connection strings but when the .exe runs I am getting the below error:
Application: xxx.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Data.SqlClient.SqlException
Stack:
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(System.Data.CommandBehavior, System.Data.SqlClient.RunBehavior, Boolean, Boolean)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(System.Data.CommandBehavior, System.Data.SqlClient.RunBehavior, Boolean, System.String, System.Data.Common.DbAsyncResult)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(System.Data.CommandBehavior, System.Data.SqlClient.RunBehavior, Boolean, System.String)
at System.Data.SqlClient.SqlCommand.ExecuteReader(System.Data.CommandBehavior, System.String)
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(System.Data.CommandBehavior)
at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(System.Data.CommandBehavior)
at System.Data.Common.DbDataAdapter.FillInternal(System.Data.DataSet, System.Data.DataTable[], Int32, Int32, System.String, System.Data.IDbCommand, System.Data.CommandBehavior)
at System.Data.Common.DbDataAdapter.Fill(System.Data.DataTable[], Int32, Int32, System.Data.IDbCommand, System.Data.CommandBehavior)
at System.Data.Common.DbDataAdapter.Fill(System.Data.DataTable)
at Dmc.V1.BatchTasks.DestinationMarketingEntityTableAdapters.HotelCodesTableAdapter.GetData()
at Dmc.V1.BatchTasks.Program.Main(System.String[])
Can anyone shed some light on this for me?
I just ran in to this issue and for me it turned out the user my app was logging to the database with didn't have execute permission on the stored procedure I was trying to running.
My app was targeting .Net Framework 4.7.2 and my app runs as a scheduled task. I got the same error message
Application: xxx.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Data.SqlClient.SqlException
If there have been recent changes to the database or to the connection string being used by the app check for a possible database permission issue.
it seems to me as a .NET Framework compatibility issue.
Problem : you have developed your application in your local machine with .NET Framework 4.5 and running the same on remote pc having .NET Framework 4.0.
Note : if you target your application to run on Higher Version of .NET Framework it wont run on below versions.
Solution : you need to target it to .NET Framework 4.0 to run on remote pc.
Step 1: right click on project - select properties
Step 2: change the Target Framework from .NET Framework 4.5 to .NET Framework 4.
Step 3: now rebuild your application and deploy.
I'm trying to generate a native image of my .NET 4.0 application using Ngen using a 64-bit Windows 7. When Platform is set to x64 (or Any CPU) - Ngen fails, complaining that 'NGen cannot proceed because Mscorlib.dll does not have a native image.'
When compiling as x86 and using the appropriate Ngen - it works fine. Also, when changing the .NET version to 2.0 - it works. (When trying to Ngen the x64 application with the x86 Ngen, it tells me I should use the 64-bit version.)
More information:
This is (part of) what I see in CMD: The ellipses (= ...) are present in the original.
1> Compiling assembly mscorlib, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089 (CLR v4.0.30319) ...
1>mscorlib, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089
.
2> Compiling assembly Accessibility, Version=4.0.0.0,
Culture=neutral, Public KeyToken=b03f5f7f11d50a3a (CLR v4.0.30319) ...
.
2>Ngen failed to generate native code for image Accessibility,
Version=4.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
because of the following error: NGen cannot proceed because
Mscorlib.dll does not have a native image (Exception from HRESULT:
0x80131F06)
Searching inside C:\Windows\assembly I found 3 mscorlib.dll's. One in GAC_32, one in GAC_64 (both in subfolders beginning with 2.0.0.0) and one in a subfolder temp.
When searching inside C:\Windows\Microsoft.NET I found six of them: two under assembly (in GAC's 32 and 64) both in folders that begin with 'v4.0...', and four in Framework's: 2 in Framework, and two in Framework64 (in each - one in 'v2.0...' and one in 'v4.0...').
Does this mean that only .NET 2.0 mscorlib's are really run as native images (when needed)? And why doesn't Ngen succeed in saving native images of .NET 4.0?
Bottom line: How do I create a native image of a .NET 4.0 application that targets x64?
This is unhealthy. The ngen-ed image of mscorlib.dll should have been created when .NET was installed on your machine. It is located in c:\windows\assembly\NativeImages_v4.0.30319_64\mscorlib\ab0a8fc3d086a3aaf942f366a12a9185\mscorlib.ni.dll. I'm not sure how well the hashed part of the directory name repeats from one machine to another.
You cannot see this file with Windows Explorer, you must use the command prompt. Go check to see if it there, something went seriously wrong when .NET was installed if it is missing. The ".NET Runtime Optimization Service" is the one that gets that job done, make sure you didn't disable it.
A standard mistake is running ngen.exe from a command prompt that isn't elevated.
I am trying to create a .app bundle of my mono program to run on Mac OS X, but despite having read virtually all articles and documentation on macpack and bundling mono, none of the methods work.
Using macpack the binaries are bundled successfully in a .app package:
macpack -m:x11 -o:. -r:sqlite3.dll -r:Nini.dll -r:extraIcons.ini -r:APP_DATABASE.db3 -r:APP_Values.db3 -r:./Documents/manual.pdf -r:GemBox.Spreadsheet.dll -r:Mono.Data.SqliteClient.dll -a:APP.exe -n:APP
. When I try to start the program from the package this happens:
FFMACM-2:MacOS dev$ open -a APP
LSOpenURLsWithRole() failed for the application /Users/dev/Workspace/Software/APP.app with error -10810.
I tried using this method but the script fails with the following error:
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Nini, Version=1.1.0.0, Culture=neutral, PublicKeyToken=691faec150a7fa7b' or one of its dependencies.
File name: 'Nini, Version=1.1.0.0, Culture=neutral, PublicKeyToken=691faec150a7fa7b'
at APP.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0
logout
I am fresh out of ideas. The Nini.dll is where it should be. I am using GTK# for the GUI.
Creating a package for MacOS X is now done using MonoMacPackager. You can find details here http://www.mono-project.com/MonoMacPackager.
However, the issue that you're seeing here is that you're missing your dll (The Nini assembly) from your package. It needs to be in your application path (after it has been bundled) to load properly.