I am working on Image processing and i have made an application in c# using EmguCV wrapper version 2.4 beta and now i want to covert it in to vb.Net so which version would be compatible for vb.Net i want to use these dll files.
Imports Emgu.CV.UI
Imports Emgu.CV
Imports Emgu.CV.Structure
Imports Emgu.CV.CvEnum
Help me to resolve this problem how can i use EmguCV in vb.Net..
Use the same version of visual studio that you used to create your c# project (or newer). Target the same version of the .net framework in each (or newer). Reference the same EnguCV dlls in each.
Functionally the languages are almost identical, however if your c# app uses unsafe code blocks then stay with c# as they're not supported in vb.net
Related
I'm really sorry about this basic question but I couldn't find anything on MSDN except an overview of the import function. I'm using Visual Studio 2013 and I've imported the System and System.IO libraries. I'm wondering if this would make the program unusable if they didn't have the libraries preloaded on their machine or if the compiler actually includes the files needed so the application is truly standalone. Thank you!
System and System.IO are part of the Microsoft .NET Framework. Without the Framework, your program won't execute at all. Most modern Windows machines already have some version of the Framework installed.
I'm having a problem with assembly resolution on an end-user machine and I believe it's related to using Portable Class Libraries....
I have a .NET 4.0 application that was originally written in Visual Studio 2010. Recently we upgraded to Visual Studio 2012 and we've created a few projects that are Portable Class Libraries. I don't believe we need these features now, but we're also building a Windows 8 Store application that might benefit from these libraries.
When I compile my project, what exactly does the portable library feature do? I expect that it allows me to run it on different frameworks without modification or recompiling.
When I look at the library in reflector dotPeek it shows the Platform attribute as:
.NETPortable,Version=v4.0,Profile=Profile5
And the references seem 2.0-ish:
mscorlib, Version=2.0.5.0
System, Version=2.0.5.0
System.Runtime.Serialization, Version=2.0.5.0
When I run the application on this end-user's machine, I see an error in the log file:
Could not load file or assembly, 'System.Core, Version=2.0.5.0...'
Googling System.Core 2.0.5.0 seems to refer to SilverLight -- which appears to be one of the targeted frameworks.
This machine does not have Visual Studio installed, but has .NET 4.0 (4.0.3 update)
Is there something I should be doing differently to compile, something I should investigate in my dependencies or something I should be looking to install on the end-user machine? What does the 2.0.5.0 refer to?
For .NET 4, you need an update (KB2468871) for Portable Class Libraries to work. From the KB Article:
Feature 5
Changes to the support portable libraries. These changes include API
updates and binder modifications. This update enables the CLR to bind
successfully to portable libraries so that a single DLL can run on the
.NET Framework 4, on Silverlight, on Xbox, or on the Windows Phone.
This update adds public Silverlight APIs to the .NET Framework 4 in
the same location. The API signatures will remain consistent across
the platform. All modifications are 100 percent compatible and will
not break any existing code.
Also see the "Deploying A .NET Framework App" section of the MSDN Portable Class Library Documentation.
EDIT: Actually, if the machine has .NET 4.0.3 installed as you mention, that should be sufficient. Can you double-check to make sure that it is actually installed?
System.Data.SQLite (SDS) is apparently the most popular way to use SQLite from a .Net application.
I was wondering if
SDS requires shipping the SQLite DLL in addition, or if SDS includes
the SQLite source code, and
SDS can be statically compiled into a
VB.Net application of it can only be shipped as a DLL?
Thank you.
To expand on my comment, SDS is a .net wrapper for unmanaged code, so you will need to ship your release code with a copy of the DLL.
As Steve mentions, there are 32 and 64bit versions of the DLL, and as i discovered after much frustration, you must have the corresponding visual c++ runtime installed on the target machine, so if you deploy the 32bit version onto a 64bit machine, it will need the 32bit c++ runtime environment installed.
An alternative that i am currently looking into but havent had time to test is csharpe-sqlite, a pure .net implementation:
http://code.google.com/p/csharp-sqlite/
Coded in c# as the name suggests, but of course usable in any .net language including vb.net
Actually it's quite easy to compile System.Data.SQLite.dll to the does not require C++ runtime. For example if you download source code and follow the build procedures you'll find statically linked (no C/C++ runtime required) copy of System.Data.SQLite.dll in the following path:
<your-src-root>\bin\<2008 or 2010>\<Win32 or x64>\ReleaseStatic
For example if your source is in C:\Work\sqlite-netFx-source-1.0.80.0 then statically linked binary for Win32 and .NET 3.5 (VS 2008) will be located in:
C:\Work\sqlite-netFx-source-1.0.80.0\bin\2008\Win32\ReleaseStatic
Furthermore since System.Data.SQLite.dll is a mixed-mode assembly consisting of a managed .netmodule and native .obj file linked together using link.exe, it is possible to build your app as a .netmodule as well and link it together with SQLite into a single mixed mode assembly.
The resulting assembly will still be either Win32 or x64, however since almost all x64 machines will have no problem running Win32 code you can just settle on Win32 as long as:
Your app is an .exe or a .dll the is always loaded into a Win32 process, and
You don't use any of x64 specific advantages such as larger address space or using unmanaged code available only in x64
I've been working with the Portable Class Libaries using the Visual Studio 11 Beta release.
I've had quite a lot of success getting WP7, Silverlight and .Net 4.5 working together within "Profile104".
However, I've not found a way to get .Net 4 supported within the same or similar profile. In particular, I'm looking for a profile where System.Xml.Linq and System.Windows.Input.ICommand are available?
Is there any way to do this? Either by using a standard profile, or by creating my own profile and then adding type forwarding?
Thanks
Stuart
No, ICommand (as well as INotifyCollectionChanged and ObservableCollection) is not available in a portable library that targets a version of .NET before 4.0. We had to make some changes in .NET to support it (mainly adding System.Windows.dll with type forwards), which aren't available on earlier versions.
I believe System.Xml.Linq is available for portable libraries on .NET 4.0.3 and above.
I'm in a VB.NET application. I have referenced some java.* namespaces in my file and am utilizing objects and methods from this namespace throughout the code. Presumably this is relying upon J# to compile.
Imports java.util
Imports java.util.zip
Imports java.io
Are these JDK namespaces fully contained in the .NET framework, or will my clients need to have Java installed when they go to run my application?
As a side note, I have not explicity referenced any external Java DLL's or anything. This is all pure .NET as far as my code is concerned.
Yes, they're within the J# DLLs, which I strongly suspect VB is referencing for you automatically. If you open your binaries up in Reflector, I'm sure you'll see a reference to vjslib.dll there.
There's no dependency on an actual JRE/JDK being installed.
Personally I would try to migrate away from them, however. If you need more compression options than System.IO.Compression it's worth looking at SharpZipLib. Microsoft no longer ships J# as a product, and the idea of trying to port all the Java 1.1.4 classes to .NET, including their quirks, has always made me nervous.
vjslib.dll doesn't even ship by default with either the framework or Visual Studio these days...