Unable to load DLL 'coredll.dll' : the specified module could not be found - compact-framework

I am writing a small application to test OpenNETCF library loading and have stumbled upon this curious message
Unable to load DLL 'coredll.dll' : the specified module could not be found
I am using Compact Framework 3.5 on a Windows Embedded 7 Compact thin client.
The code is
using System;
using System.Linq;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using OpenNETCF.Threading;
namespace Windows7EmbeddedTest
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
MessageBox.Show("Starting the test");
bool notRunning;
NamedMutex mutex = new NamedMutex(false, "myappname", out notRunning);
MessageBox.Show("test went well!");
}
}
}
Any ideas how this could be fixed? I searched my Windows Embedded Compact 7 thin client for coredll.dll and nothing came up. My understanding is that it is an integral part of Windows CE devices. Then why can't OpenNETCF find it on Windows Embedded Compact 7 machine? Do I need to download/install this dll manually? Register it?
If Windows Embedded Compact 7 ships with it, what would be the path to look for it?

Are you absolutely positive that your thin client device is running Windows Embedded Compact (Windows CE) and not Windows Embedded Standard (WES)?
The reason I ask is because coredll.dll is a fundamental piece of the Windows CE OS. It's the analog to the desktop's kernel32.dll and user32.dll (plus several others) all wrapped up into one. It's impossible to have a Windows CE OS that doesn't contain coredll.dll.
Normally it's a hidden file, so it doesn't show in Explorer unless you "show hidden files" or use something like Remote File Viewer, but the fact that the .NET loader can't find it makes me suspect it's not there, which in turn makes me believe you're running WES and not CE.

Related

What is the windows10 SDK replacement for the 'good old' directx namespace "microsoft.directx.audiovideoplayback"?

I've been using the "Audio" class from the DirectX SDK namespace "Microsoft.DirectX.AudioVideoPlayback".
I'm using this audio class because it gives me control of the volume and balance for each individual audio file I play, and gives me simple control of play-timing.
Now that directX has been integrated into the windows 10 SDK (As I've understood), how do I use the same object using the windows SDK in my VB.NET (.NET framework) project?
Thanks for your time!

webview2 on .net 4.7.2 using c# or vb - NOT CORE

Will WebView2 work with "Visual Studio 2017" - either VB or C# - for .NET 4.7.2 - winforms
NOTE CORE, as its .net 4.7.2 so I can't do all the "await" code that is required I don#'t think.
Is there or does someone have any working small same code showing how to get webview2 to work in the above setup?
Again, c# or vb, .net 4.7.2 NOT CORE
Angrid
I might get where you're coming from with the question, actually.. This was painful
I have canary channel edge dev installed, check.. VS2017 and 2019, check..
I had a play around with WebView2 in a new WinForms 472 Project in VS 2017 - the only way I could get the nuget package to add a usable Microsoft.Web.WebView2.WinForms reference/namespace was to add a prerelease package. Addining a non prerel nuget showed nothing in the references
After adding the latest pre-rel package I founf that adding the control to the form and setting the Source (in code or designer) merely elicited a NullReferenceException when the source was being set
I followed the instructions in the Getting Started documentation to the letter, but I still got the NullReferenceException as soon as any form of interaction took place with the control
I opened the official winforms example in VS2017 and got an an error that the project file couldn't be loaded because "Project file is incomplete. Expected imports are missing."
Switched to opening the official sample in VS 2019, resolved the complaint about not having targeting pack 461 installed by editing the csproj to a pack I did have, and reloading the project.. It builds and runs.. But it's .NET core
A lot more messing around (always hitting the WebView2 NullReferenceException as soon as a property was set on it, or it was added to the form's controls collection), and I eventually (by chance) caught this tooltip for the WebView2 constructor:
Something you don't really see if the forms designer did the constructing..
So once I'd set up some code like:
public partial class Form1 : Form
{
private WebView2 x = new WebView2();
public Form1()
{
InitializeComponent();
}
private async void Form1_Load(object sender, EventArgs e)
{
await x.EnsureCoreWebView2Async();
x.Dock = DockStyle.Fill;
x.Source = new Uri("https://stackoverflow.com");
this.Controls.Add(x);
}
}
I started hitting a BadImageFormatException - that was resolved by setting the app to be x64 instead of AnyCPU/X86
And finally it works, in WinForms:
What a fuss..
TLDR:
Install Edge Canary Channel
Install latest prerelease package to a new winforms project
Consider pasting the code I put above; Ensure... seeminglt must be the first thin you do after you construct the control
Change the bitness of your project if you get a BadImageFormatException

PInvoke works with Windows 7 but fails in Windows XP

I have an application that uses a third party native C dll. Everything works well on a Windows 7 machine with .Net 4 but fails on Windows XP (SP3) with .Net 4.
I get the following exception on Windows XP machine.
Unhandled Exception: System.AccessViolationException: Attempted to read or write
protected memory. This is often an indication that other memory is corrupt.
When I debug,
First-chance exception at 0x10069e1d in CacheInteropTest.exe: 0xC0000005: Access violation reading location 0x00000000.
this is my simplified test application code:
public unsafe class Program
{
[STAThread]
static void Main(string[] args)
{
var status = CacheEnd();
Console.ReadKey(true);
}
[SuppressUnmanagedCodeSecurity]
[DllImport("cachet.dll", EntryPoint = "#24", CallingConvention = CallingConvention.Cdecl, SetLastError = true)]
internal extern static int CacheEnd();
}
I compiled the above program on Windows XP (SP3) 32 bit and copied to a Windows 7 machine and ran, it did not give any exception. The third party dll is available in the same folder as the executable.
I found many replies for issues related to AccessViolationException, particularly this
AccessViolationException in P/Invoke call is a close match.
Another site has kind of an overview about PInvoke and memory related issues here
http://dotnetdebug.net/2006/04/17/pinvoke-and-memory-related-issues/ but does not help me in this case.
The third party dll is a database kernel and provides multi-threaded database access (maintains one connection per thread). In the documentation of the API it was mentioned that the dll must be statically linked and C++ application that consumes this dll on Windows XP works well too.
I think the problem is in the implementation of the native dll, but why it works well on Windows 7?
Any one has any idea what could be going wrong on Windows XP?
The native function proto type provided by the vendor is
extern int CFPROTOD(CacheEnd,(void));
So I guess the issue is not related to calling conventions.
The issue is because of a limitation in Windows. The static linking requirement for the API came from this limitation that was already known to the vendor.
http://support.microsoft.com/kb/118816 explains the issue in Windows. Looks like this has been fixed in Win 7

compiling a .net application with either a 32-bit or 64-bit dll

I have an application that we wrote here at work that uses the SharpSVN wrapper for SVN. It has served us well of the past few years. However, we have started bringing in 64-bit systems and our application cannot seem to access the SharpSVN dll on these systems.
I have downloaded the 64-bit version of the SharpSVN dll and I am wondering what to do next. I cannot stop my 32-bit users from using the application, so I need to be able to compile for both platforms. Luckily, with this application, we split different layers of the ntier stack into separate projects within the solution so my business layer that utilizes the SharpSVN dll is on its own.
How would I go about compiling both a 32-bit and 64-bit version of my application without having to maintain two copies of the project?
Build your tool using the x86 platform (as opposed to Any CPU), and it will be loaded as x86 code even on 64-bit systems.
Or you can do something like
class SharpSvn64 {
[DllImport("sharpsvn64.dll")] extern public static void DoSomething();
}
class SharpSvn32 {
[DllImport("sharpsvn32.dll")] extern public static void DoSomething();
}
class SharpSvn {
static readonly bool Is64 = (IntPtr.Size == 8);
void DoSomething() {
if (Is64)
SharpSvn64.DoSomething();
else
SharpSvn32.DoSomething();
}
}
Edit: Since SharpSVN is managed, PInvoke wouldn't be the answer, so building x86 executables are probably the way. Or, if the interface is identical, you MAY get away with subscribing to the AddDomain.AssemblyResolve event and choose which assembly you want in that. I don't know if this is a good idea, though.
From the description, it sounds like your vb.net application is built with the Any CPU option, which means it would run as a 64-bit application on a 64-bit machine. In that case, it would not load the 32-bit DLL.
Rather than try to use both a 32-bit and 64-bit version, you should be able to just change it to run as 32-bit. Simpler deployment. Under the project properties build tab, choose x86.

How can I make a .Net 4.0 Exe ask the user to download .Net 4.0 framework / redistributable before running this exe?

I thought that latest Matlab does this automatically. I have tested the following exe on a clean Win XP VM:
namespace DotNetTest
{
using System.Windows.Forms;
class Program
{
static void Main(string[] args)
{
MessageBox.Show("Howdy!");
}
}
}
When I run it on a computer which has all these installed, it does show the message box and a window. When I run it on a clean VM, I get this error:
Title: DotNetTest.exe - Application Error
Icon: Error
Buttons: {OK}
Message Body: The application failed to initialize properly (0xc0000135). Click on OK to terminate the application.
I would expect better from MSFT geniuses. Why cannot every .Net exe contain a tiny bit of overhead and have the very first bytes of it do the work of detecting if .Net is installed and presenting a better message.
Is there some sort of setting that I can flip to fix this? All of the settings were default ones provided by VS2010 when I created a new project.
Thank you.
This is what you use an installer for. In .net this is simple, you just "publish" your project and you get an installer that makes shure that .net is installed and such. The application itself should never have to worry about that.
As Alexandr says, you should really use the installer for this. If that's not possible, you'd have to write an unmanaged exe to run first and then either start the .net exe or tell the user to download the framework depending on if it's already installed.