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...
Related
Here is the setup when I am getting this error:
Project "main" based on Core 3.1 and of type console application. Does not have a reference to System.Data.SqlClient and does not need one.
It calls project "process" also based on Core 3.1 of type class library. Does not have a reference to System.Data.SqlClient and does not need one.
"Process" calls project "service" based on Core 3.1 of type class library. This project needs System.Data.SqlClient and has a reference to a package "System.Data.SqlClient (4.5.1)".
When debugging "main", when it gets to "service", the first time it reference SqlConnection, it errors with message "system.data.sqlclient is not supported on this platform"
Why am I getting this error and how can I fix it.
Note: When I add a refernce to System.Data.SqlClient in project "main" - no error, but of course as "main" does not need System.Data.SqlClient, it should not have one.
When I test "service" using xUnit, no errors, it works OK
Thanks
According to the document:
The Microsoft.Data.SqlClient NuGet package includes a number of DLLs
supporting different .NET targets and different runtime platforms. If
you are getting a PlatformNotSupported Exception when you don't think
you should be, it ultimately means your application is not loading the
appropriate DLL. There could be a number of reasons for this. The
NuGet package structure and infrastructure around referencing and
loading referenced NuGet packages includes logic that allows a package
to contain multiple DLLs which implement support for different .NET
and platform targets. Meaning a different DLL for .NET Framework, .NET
Core, .NET Standard, Windows, Linux, etc. The NuGet infrastructure
will automatically reference and load the appropriate DLL based on
your application's needs.
If your application loads a DLL from a NuGet package directly, it
bypasses all this logic and probably loads the incorrect DLL. The DLL
in the NuGet package under
lib/netstandard2.0/Microsoft.Data.SqlClient.dll is basically the
fallback DLL for any unsupported target and simply throws the
PlatformNotSupported exception for any call. This is a nicer exception
than what you would otherwise get when running on a platform that does
not have a DLL built for it. Ultimately, you want to use the NuGet
package reference infrastructure or you would have to implement all
this target framework and platform support logic yourself when
determining which DLL to load.
Additionally, the NuGet package contains all the dependency
information for the SqlClient library and facilitates the downloading
and referencing of dependencies. If you reference and load an
individual DLL manually, it is up to you to ensure all dependencies
are also available to the SqlClient library.
I suggest you could try to use Microsoft.Data.SqlClient instead. More details about cheat sheet for porting from System.Data.SqlClient to Microsoft.Data.SqlClient, you could refer to this article.
I have a piece of code that compiles for both the Silverlight and the .NET targets. It depends on Json.NET and SharpZipLib. My goal is to make a portable library that Silverlight and .NET projects can both link against.
Since there is no version of SharpZipLib targeting "portable-net40+sl50", I have a problem.
However, if I knew how, I would be willing to write the wrapper code myself.
So: How can I write a portable library that depends on Silverlight's SharpZipLib when being linked against from Silverlight and depends on .NET's SharpZipLib when being linked against from .NET?
Is that at all possible or is that something only Microsoft can do?
If your code uses a limited sub-set of the SharpZipLib API, you could create a "dummy" PCL library comprising this API subset, but without any functionality implemented.
What you then must do is to change the strong name (assembly name and signing) and version of the existing .NET and Silverlight SharpZipLib:s to be the same as your "dummy" PCL SharpZipLib and re-compile the platform specific libraries as well.
With this set of assemblies (PCL, .NET and Silverlight) you will now be able to consume the PCL library from other PCL libraries. In a platform specific application that makes use of PCL libraries that in turn consumes the SharpZipLib library, you should explicitly reference the platform specific SharpZipLib library that has the same strong name and version as the PCL analogue.
You should find more about this technique ("bait-and-switch") here and here. The PCL Storage project is also a good example of where this technique has been applied.
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?
So far as I'm aware, most of the below types are now, and have always been, defined in mscorlib and/or System.dll.
However, in looking in the v4 framework directories (I have 4.5 installed, not sure if it also exists in Vanilla v4), I find an assembly called System.IO.dll.
Examining it in reflector, I can't see any actual code. All I can find are the following entries:
[assembly: TypeForwardedTo(typeof(BinaryReader))]
[assembly: TypeForwardedTo(typeof(BinaryWriter))]
[assembly: TypeForwardedTo(typeof(EndOfStreamException))]
[assembly: TypeForwardedTo(typeof(FileNotFoundException))]
[assembly: TypeForwardedTo(typeof(InvalidDataException))]
[assembly: TypeForwardedTo(typeof(IOException))]
[assembly: TypeForwardedTo(typeof(MemoryStream))]
[assembly: TypeForwardedTo(typeof(SeekOrigin))]
[assembly: TypeForwardedTo(typeof(Stream))]
[assembly: TypeForwardedTo(typeof(StreamReader))]
[assembly: TypeForwardedTo(typeof(StreamWriter))]
[assembly: TypeForwardedTo(typeof(StringReader))]
[assembly: TypeForwardedTo(typeof(StringWriter))]
[assembly: TypeForwardedTo(typeof(TextReader))]
[assembly: TypeForwardedTo(typeof(TextWriter))]
All pointing back to mscorlib (I think, haven't checked all of them). I've had a look around, and I can't see any framework version (e.g. silverlight, compact, etc) where these types aren't in mscorlib. So, does anyone know why this assembly exists (and why now)?
You found a reference assembly. That may sound odd, since you definitely don't use such a reference assembly in a .NET project that targets .NET >= 4.0. You normally get them from the C:\Program Files (x86)\Reference Assemblies directory on your dev machine. But that is not the only scenario in which a compiler is used. You also use a compiler when you use System.CodeDom in your program or depend on XML serialization.
Specific about System.CodeDom and XML serialization is that the compiler runs on your user's machine. And that you cannot target a specific .NET Framework version. Your user's machine does not have the targeting packs that your machine has. So its gets whichever version happens to be installed on the machine. The files in C:\Windows\Microsoft.NET\Framework\v4.0.30319 contains the reference assemblies that match that installed version. If the machine gets updated with another .NET 4.x release then those reference assemblies get updated as well.
Not the only possible scenario, likely that you'll also use them when you build from the command line. Or on a build server and decided to not pay for a VS license, very bad idea. Or in an ILMerge command, excessively bad idea. Those scenarios are a lot more troublesome. It works okay as long as the built assembly stays on the same machine. But not if they travel to another one machine, one that has a different framework version installed. That can produce pretty mystifying runtime exceptions, evident in this Q+A.
System.IO.dll is fairly exotic. You are only going to need it when you run System.CodeDom with a reference to a PCL assembly. Its primary role is to hide declarations, the kind that should not be used in the profile you picked. The System.IO namespace needs hiding because these types cannot be used when you target WinRT. But otherwise the reason that it doesn't contain any types, the [TypeForwardedTo] tells the compiler that the type is supported on a desktop machine and to look for the declaration elsewhere, mscorlib.dll