A native exception occurred in .Net EXE - c#

I have developed a C#.net windows form application to get and update data from /to a SQL server CE database.While I'm running this app on windows ce 6.0 machine, getting following error:
A native exception occurred in ItemDB.exe(my exe name).
Details:
Exception code : 0x80000002
Exception address: 0x40e843b4
Faulting module: sqlceme35.dll
offset: 0x000043b4
at
NavigateMethod.GetKeyInfo(parm1,parm2,...)
at
SqlCEDataReader.FillMetaData(command)
at
sqlCeCommand.InitializeDataReader()
So I searched in net and found this link:
http://go4answers.webhost4life.com/Example/cant-find-pinvoke-dll-sqlceme35dll-49162.aspx
http://blogs.msdn.com/b/sqlservercompact/archive/2007/10/26/can-t-find-p-invoke-dll-sqlcemenn-dll.aspx
As suggested, I copied ZIP file(because, I didn't get Cab files) and changed this to .Cab.Then I tried to run Cab,But, its saying "this is not a valid wince setup file".
Hope I explained it clearly.Could anyone please help me?

This is almost always caused by a SQL CE version difference between what you compiled against on the PC and what you have deployed on the device. Make sure that the SQL CE version number is identical in both your project references and what is on the device. Typically I add the reference not from the ".NET" tab in references, but I specifically brows to the reference so I know exactly which file is being used, and then manually deploy SQLCE from the same location to the device.
*EDIT
The location you should be looking for the files to deploy is here:
C:\Program Files (x86)\Microsoft SQL Server Compact Edition\v3.5\Devices\wce500\armv4i
And your project reference should point here:
C:\Program Files (x86)\Microsoft SQL Server Compact Edition\v3.5\Devices\System.Data.SqlServerCe.dll

Related

Updating Oracle 12.1 to 12.2 Oracle Dependency Error occurs

We have recently been struggling to update our C# applications with the new Oracle DLLs. We create our software for multiple platforms. So our software solution is both a winform desktop application and a ASP.NET MVC webapplication.
Both applications run Oracle 12.1 stand-alone perfectly. We add all necessary Oracle DLLs with the redistribution of our software. So the desktop application has all the DLLs within the MSI and the publish of the website has all the DLLs in the ~\Bin. Making sure that when the website is hosted on IIS the web application runs. This way our customers do not need to install Oracle Client.
Now comes the problem, since updating to Oracle 12.2 it's not possible for us to run the web application any more. The desktop application still runs fine although since Oracle 12.2 we get a Firewall Exception message, if we want to allow our desktop application to connect to the internet.
We didn’t get that message in Oracle 12.1 or below:
We have published our webapplication with all the new Oracle dll’s (the same dll’s as desktop and the same way as for when the webapplication has Oracle 12.1) and since then we are not able anymore to connect to our Oracle databases. We get the error below:
Unable to load DLL 'OraOps12.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
System.TypeInitializationException: The type initializer for 'Oracle.DataAccess.Client.OracleConnection' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'OraOps12.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at Oracle.DataAccess.Client.OpsInit.CheckVersionCompatibility(String version)
at Oracle.DataAccess.Client.OracleInit.Initialize()
at Oracle.DataAccess.Client.OracleConnection..cctor()
--- End of inner exception stack trace ---
We have checked, but YES the DLL is there. We also put it in different locations to see if this would work but no.
These are the DLLs we are using:
The strange thing is that when we copy our desktop application to the server, the desktop application runs fine! The desktop application has the exact same DLLs as the web application!
The DLLs we are using for both desktop and web application are from the XCopy folders of Oracle:
http://download.oracle.com/otn/other/ole-oo4o/ODAC122010Xcopy_32bit.zip x86
http://download.oracle.com/otn/other/ole-oo4o/ODAC122010Xcopy_x64.zip x64
There are more people struggling with this issue, here is what we have found so far:
Oracle 12.2 needs minimum .NET Framework 4.5.2 our server has 4.6 and up
The rights of the DLLs are set correctly and may be used by IIS
We have for our x86 web application enabled 32-bit application in the Advanced Settings window
We have set the environment making sure the right DLLs are added to the environment
In Visual Studio we made sure that the references are: Copied if newer and Local copy is set to true
Our application are full x86 or x64 NOT anyCPU build.
We have checked our Regedit, Machine.config and GAC for any possible left-over of other Oracle versions.
Redownloaded the xcopy zip and copied the files again
Server has DISABLED firewall (development)
Oracle.DataAccess.Client Dependencies this is more or less our method to!
Our server-specs:
Windows Server 2012R2 DataCenter (clean)
X64-based pc
using IIS 8.5
This way our customers do not need to install Oracle Client.
I think this is a bad idea, I do not recommend doing it like this.
Either
Ask your customer to install Oracle Client (include ODP.NET provider) by themselves using standard Oracle downloads
or
Use the ODP.NET Managed Driver, then you don't need any further installation. You just have to provide the Oracle.ManagedDataAccess.dll with your application.
It it hard to determine your problem without further information, there could be several reasons:
Missing DLL -> For this I cannot help you, make a normal Oracle installation
Wrong PATH settings. -> Ensure %ORACLE_HOME% and %ORACLE_HOME%\bin are in
How did you check your GAC? Did you usegacutil.exe version 4.0? Older version 3.5 does not show 4.0 (and above) assemblies.
You may have a conflict with 32-bit vs. 64-bit Oracle installation. In case you need both of them, follow this installation instruction: BadImageFormatException. This will occur when running in 64 bit mode with the 32 bit Oracle client components installed
Version of ODP.NET does not match with version of installed Oracle Client. The major release (e.g. 11.1, 11.2, 12.1, 12.2) has to be the same for both.
You can also use Process Monitor tool, in order to see which DLL and/or registry entry is missing.

Using SqlPackage.exe on a server without SSMS installed

I have a windows 2012 server. The server can access my SQL database.
I don't have access to the SQL database server, and I don't have access to install SSMS on the windows 2012 server running my website.
I want to use SqlPackage.exe to update my database scheme with a .dacpac file
I get the following error:
Unhandled Exception: System.TypeInitializationException: The type initializer for 'Microsoft.SqlServer.Dac.DacPackage' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.SqlServer.Dac.DacServices' threw an exception. ---> System.TypeInitializationException: The type initializer for 'SqlSchemaModelStaticState' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.TransactSql.ScriptDom, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
Is there some way that I can give SqlPackage.exe the needed Microsoft.SqlServer.TransactSql.ScriptDom without installing SSMS on the server?
If it is not possible, is there then an exsisting stand-alone exe out there that can do the job?
SqlPackage come with SMSS or SQL Data Tools.
i see no other alternative than installing one of these two binaries to deploy dacpac, it is also possible from most computer running visual studio, because sql data tools is part of the defaults VS install.
https://msdn.microsoft.com/en-us/library/mt204009.aspx
You can download any of these nuget packages (depending on desired version and platform). There you will find any missing DLLs.
https://www.nuget.org/packages?q=microsoft.sqlserver.dac+microsoft.sqlserver.dacfx
(Or you could write your own C#/Powershell application, using Microsoft.SqlServer.Dac.DacServices directly from the package.)
Since Aug 2018 your best bet is to download the "Windows .NET Core .zip file" from https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-2017#get-sqlpackage-net-core-for-windows
This seemed to be the "smallest" package I could install and still get the tool (sqlpackage.exe) that works.
Microsoft® SQL Server® Data-Tier Application Framework (June 30 2016)
https://www.microsoft.com/en-us/download/confirmation.aspx?id=53013
the above installed it to the below directory when I install it (today)
C:\Program Files\Microsoft SQL Server\130\DAC\bin\SqlPackage.exe
APPEND:
Mid 2020 URL Update :
Microsoft® SQL Server® Data-Tier Application Framework (18.3.1)
https://www.microsoft.com/en-us/download/details.aspx?id=100297
Usually you install SSDT to do this. I'm not sure if theres a portable version of SSDT somewhere that doesn't require an install if thats what you actually require.

"WireUpCoreRuntime" tasks fails unexpectedly with a System.BadImageFormatException

I am having trouble with a MSBuild 14.0 issue. I am creating a UWP/x64 Application (we have written the source to be able to run on Windows 8.x, Windows 10 and now Windows 10 Mobile. My current environment is VS 2015 update 1 running on Windows 8.1. My code exists on a TFS 2013 local server. I have a build controller and build agent installed from TFS 2015 running on a separate server (server 2012 R2) assigned to my XAML Build Definition. I can build locally on my server within a Visual Studio 2015 session. When I Queue a Build. I get the following error:
C:\Program Files
(x86)\MSBuild\Microsoft.NetNative\Microsoft.Net.CoreRuntime.targets
(235): The "WireUpCoreRuntime" task failed unexpectedly.
System.BadImageFormatException: An attempt was made to load a program
with an incorrect format. (Exception from HRESULT: 0x8007000B) at
Microsoft.Build.Net.CoreRuntimeTask.WireUpCoreRuntime.CopyWin32Resources(String
lpPEFileToReadResourcesFrom, String lpPEFileToInsertResourcesInto)
at
Microsoft.Build.Net.CoreRuntimeTask.WireUpCoreRuntime.InternalExecute()
at Microsoft.Build.Net.CoreRuntimeTask.WireUpCoreRuntime.Execute()
at
Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at
Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()
Initially I thought this was an environment issue with the build system not on a Windows 10 platform, however, if this was the case I would not be able to build locally in Visual Studio.
I have Disabled AV on my server for a build with no luck.
the build Configuration is x64/Release. I have also tried x64/Debug, ARM/Debug and ARM/Release. none of these build configurations work. I think it might have something to do with .NetNative but I cannot be certain.
This error usually occurs when the file image of a DLL or executable program is invalid, check following things first:
Make sure that you are not using a component that was created with a
different version of the .NET Framework.
Make sure that the file
image is a valid managed assembly or module.
Detailed information: Troubleshooting Exceptions: System.BadImageFormatException

System.Data.SqlServerCe.dll SQL Server CE 3.5 reference missing after generating .exe file using InstallShield Limited Edition Project

I am using VS 2013 with InstallShield Limited Edition Project.
Everything is working fine in development environment where I have created reference to System.Data.SqlServerCe.dll
After I generate .exe file and install my application it is unable to find reference for SQL Server CE 3.5 thus automatically gets reference for SQL Server CE 4.0 and gave an error.
Incompatible Database Version. If this was a compatible file, run repair. For other cases refer to documentation. [ Db version = 4000000,Requested version = 3505053,File name = \?\C:\Users\someuser\AppData\Local\testapp\testdb.sdf ]
I have tried going through "this" article on MSDN but I can't find any publish tab in properties of my project.
Furthermore I am deploying System.Data.SqlServerCe.dll and all 7 32bit version SQL Server CE 3.5 dlls with my setup.
sqlceca30.dll
sqlcecompact30.dll
sqlceer30en.dll
sqlceme30.dll
sqlceoledb30.dll
sqlceqp30.dll
sqlcese30.dll
No, the issue is that your database file is in 4.0 format. As you can see from the error message, the engine is trying to open a 3,5 file, but gets a 4,0 file instead. So your application is using the 3,5 engine.
The problem was when I was trying to deploy msi package using InstallShield it used different build setting(x64) than my current setting(x86) which was causing my application to get the reference of x64 Sql Server CE 4.0 files.
So it was fixed by changing setting of singleimage compiling option.

Could not load file or assembly 'VSLangProj80'

Its an Asp.net website . Running good on local development system . VS2010 and .NET 4 . When uploading to web server it throws an assembly could not be loaded error in my web.config file .
I sort it on google by changing framework from 3.5 to 4 will arise this error . My doubt is there any way to lock or persist the integrity of an assembly file through out the .NET versions .
My hosting server URL : http://ananth7453-001-site1.mywindowshosting.com/
Thanks for your time
VSLangProj80 is installed as part of Visual Studio which is why your site works on your development machine. Copy the DLL to your project folder and then replace the reference in Visual Studio with the copy.
On my machine VSLangProj80 is located at C:\Program Files (x86)\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\VSLangProj80.dll
I want to share the solution I encountered as I have the same issue encountered. Over the years, our web server is installed with different Visual Studio programs, such as Shell (integrated mode) and Tools for Applications 2.0 ENU. There's also Tools for Office Runtime. It took us a while to isolate which of these installs conflicts to the application we are trying to install.
We found out that our application has the latest version of VSLangProj80.dll and the one in our server is using older version. Without changing our build since it is working on our UAT environment, we manage to un-install the Tools for Application 2.0 ENU. Removing this one out of our production server resolved this issue.

Categories

Resources