Get assembly location in CoreCLR - coreclr

Under CoreCLR, I cannot get the assembly location like I was able to under .NET Framework.
It appears that Location is not a member of Assembly and that the static methods on Assembly, such as GetExecutingAssembly, are also gone.
What is the preferred method to get the assembly directory, or any directory information about my running program?
I've tried CoreCLR versions:
1.0.0-beta5 coreclr x64
1.0.0-beta6 coreclr x86

Since you mention 1.0.0-beta6 I assume you are talking about DNX.
You can use IApplicationEnvironment. That will give you the name and base path of the application.
Assembly.Location would be tricky because you can have code that's compiled on the fly so the assembly is not in a location that you might expect.

Related

Unable to Scaffold-DbContext with EntityFrameworkCore.Jet

I've been trying to generate the Entity Framework Models for an existing Database.
I'm using the EntityFrameworkCore.Jet-Provider (v2.1.0 preview 5) with EntityFrameworkCore (v2.1.2) in Visual Studio 2017. I used the following command within the Package Manager Console:
PM> Scaffold-DbContext -Connection "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\..\workplace\TestProject\demo.accdb;Jet OLEDB:Database Password=****;" -Provider EntityFrameworkCore.Jet -OutputDir Models -verbose
which gave me this output:
Using project 'TestProject'.
Using startup project 'TestProject'.
Build started...
Build succeeded.
...
Using assembly 'TestProject'.
Using startup assembly 'TestProject'.
Using application base 'C:\..\workplace\TestProject\bin\Debug'.
Using working directory 'C:\..\workplace\TestProject'.
Using root namespace 'TestProject'.
Using project directory 'C:\..\workplace\TestProject\'.
Using configuration file 'C:\..\workplace\TestProject\bin\Debug\TestProject.exe.config'.
Finding design-time services for provider 'EntityFrameworkCore.Jet'...
Using design-time services from provider 'EntityFrameworkCore.Jet'.
Finding design-time services referenced by assembly 'TestProject'.
No referenced design-time services were found.
Finding IDesignTimeServices implementations in assembly 'TestProject'...
No design-time services were found.
System.InvalidOperationException: Der 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert.
...
Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
Der 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert.
Which translates to
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
At first I expected this to be the case and did some research which brought me here and I followed the given solution, but the Problem persisted. Looking into the folder C:\Program Files (x86)\Common Files\microsoft shared contains the subfolders OFFICE12, OFFICE14 and OFFICE16 which each hold an ACEOLEDB.DLL.
Confirmed through use in a Code First approach the provider is actually registered and usable! But when used in the Package Manager it can't be found. Am I missing some specific reference?
Since the exact same ConnectionString is working when used with CodeFirst what could be the Issue? Or is EntityFrameworkCore.Jet not enabled for Database-First Approach?
Revisiting this Issue, I realised that the Compile Configuration had been set to Any CPU.
Mind that I have installed office 32bit and the corresponding 32bit driver set (see this and this)
While Code First will run in the Any CPU Configuration, the Package-Manager-Console does have a problem with this. PMC seems to be trying to resolve the x64-provider in this configuration.
Switching this setting to x86 in Visual Studio 2017 resolved that issue:
Using assembly 'TestProject'.
Using startup assembly 'TestProject'.
Using application base 'C:\..\workplace\TestProject\bin\x86\Debug'.
Using working directory 'C:\..\workplace\TestProject'.
Using root namespace 'TestProject'.
Using project directory 'C:\..\workplace\TestProject\'.
Using configuration file 'C:\..\workplace\TestProject\bin\x86\Debug\TestProject.exe.config'.
After switching the Compile Configuration of the Project/StartupProject to x86 PMC is able to resolve the Microsoft.ACE.OleDb.12.0 provider and successfully scaffold the database.

Matlab .Net Assembly compatible with .Net Core1.1

I am trying to use Matab module compiled as .Net assembly in a .Net Core Project, but I receive the following exception:
Unhandled Exception: System.IO.FileNotFoundException: Could not load
file or ass embly 'MWArray, Version=2.17.1.0, Culture=neutral,
PublicKeyToken=e1d84a0da19db8 6f'. The system cannot find the file
specified. at ConsoleAppCore1._1.Program.Main(String[] args)
MCR_R2017b_win64_installer.exe is installed on the system and I am able to load same Matlab module in .Net4.5 project.
Any clue to make it work with .Net Core1.1?
Simply NO - mathworks supports only "classic"/desktop .net framework on Windows platforms
Please refer to this: mathworks doc

TypeInitializationException accessing MonoGame GraphicsAdapter.Adapters, could not load type 'SharpDX.Rectangle'

Converting VB code from XNA 3.1 to MonoGame.
Any attempt to access class GraphicsAdapter throws the exception below. For example, trying to enumerate GraphicsAdapters. On this line:
For Each adapter As GraphicsAdapter In GraphicsAdapter.Adapters
Result is an exception:
System.TypeInitializationException occurred
HResult=-2146233036
Message=The type initializer for 'Microsoft.Xna.Framework.Graphics.GraphicsAdapter' threw an exception.
Source=MonoGame.Framework
TypeName=Microsoft.Xna.Framework.Graphics.GraphicsAdapter
StackTrace:
at Microsoft.Xna.Framework.Graphics.GraphicsAdapter.get_Adapters()
at ...my code...
InnerException:
HResult=-2146233054
Message=Could not load type 'SharpDX.Rectangle' from assembly 'SharpDX, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b4dcf0f35e5521f1'.
Source=MonoGame.Framework
TypeName=SharpDX.Rectangle
StackTrace:
at Microsoft.Xna.Framework.Graphics.GraphicsAdapter.CreateAdapter(Adapter1 device, Output monitor)
at Microsoft.Xna.Framework.Graphics.GraphicsAdapter.PlatformInitializeAdapters(ReadOnlyCollection`1& adapters)
at Microsoft.Xna.Framework.Graphics.GraphicsAdapter..cctor()
Note the inner exception:
Could not load type 'SharpDX.Rectangle' from assembly 'SharpDX, ...Version=4.0.1.0, ...
The project references these assemblies (among others):
MonoGame.Framework version=3.6.0.1625
from NuGet "MonoGame.Framework.WindowsDX", file
packages\MonoGame.Framework.WindowsDX.3.6.0.1625\lib\net40\MonoGame.Framework.dll
SharpDX version=4.0.1.0
SharpDX.Direct2D1 version=4.0.1.0
SharpDX.Direct3D9 version=4.0.1.0
SharpDX.DXGI version=4.0.1.0
SharpDX.Mathematics version=4.0.1.0
So I don't see why it would fail this way.
What could be wrong? Not compatible with this SharpDX version?
NOTE: These are all up-to-date packages from NuGet, in Visual Studio 2015. Targeting .Net 4.5.2.
UPDATE
To prove it isn't a problem with SharpDX, I put this line before that GraphicsAdapter line:
Dim testRect As SharpDX.Rectangle = New Rectangle()
This successfully created testRect. No Exception until attempt to access GraphicsAdapter. Also tried all the other Shared (static) properties of GraphicsAdapter, such as GraphicsAdapter.DefaultDevice. Any one fails with same exception.
I posted the same question to MonoGame forums:
http://community.monogame.net/t/solved-typeinitializationexception-accessing-graphicsadapter-adapters-could-not-load-type-sharpdx-rectangle/9803
Cause of problem:
Current release of MonoGame.Framework for WindowsDX (Windows OS + DirectX drivers), 3.6.0.1625 is built against SharpDX 2.6.3, and is not compatible with more recent SharpDX versions.
(Interim) Solution:
The developer branch of MonoGame does target the current SharpDX. Builds can be obtained from MonoGame's teamcity (free registration required).
Tested MonoGame.Framework build 3.7.0.994; it worked with SharpDX 4.0.1:
http://teamcity.monogame.net/viewLog.html?buildId=56483&tab=artifacts&buildTypeId=MonoGame_PackagingWindows
That build installs most SharpDX dlls to
C:\Program Files (x86)\MonoGame\v3.0\Assemblies\Windows
However, SharpDX.Mathematics.dll is currently missing,
so I still install SharpDX from NuGet, rather than using those.
Standard location for MonoGame releases:
(look for at least 3.7, which is not there yet, as I write this):
http://www.monogame.net/downloads/
(If instead of NuGet packages for MonoGame and SharpDX, I had downloaded MonoGame 3.6 installer and used its version of SharpDX dlls at C:\Program Files (x86)\MonoGame\v3.0\Assemblies\Windows, then I would not have had this incompatibility. However, that was not recent enough SharpDX for my purposes. This should be resolved by release of MonoGame 3.7)

How do I reference a UWP+NET46 portable library from a .NET 4.6 console application?

I have a portable class library project that targets .NET 4.6 and Universal Windows Platform. This class library contains just one class with the following line of code in its constructor:
Directory.CreateDirectory(Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString()));
Now I create a new .NET 4.6 console application project in the same solution and add a project reference to the portable class library. Calling the method that houses the above line of code results in the following exception at runtime:
Could not load file or assembly 'System.IO.FileSystem, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
What am I doing wrong here? There are no compile-time errors or warnings.
Things I have tried: add missing(?) NuGet package manually
It seems that System.IO.FileSystem is a library delivered via NuGet, as part of the Microsoft.NETCore mega-package. Okay, perhaps I need to explicitly add this package to any project that uses my portable class library. I attempt to do so.
Could not install package 'Microsoft.NETCore.Platforms 1.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.6', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
No luck with this approach.
Things I have tried: create a project.json file
While there is no clear info on the web, I read a few tidbits about a new project.json based NuGet harness or build system. Just to experiment, I created the following project.json file in my console application project:
{
"dependencies": {
},
"frameworks": {
"net46": { }
},
"runtimes": {
"win-anycpu": { }
}
}
It works! The runtime error goes away! However, I soon found that this was either not the right solution or not a complete solution. I started writing some code to read configuration section values, which involved making use of the IConfigurationSectionHandler interface, and got the following compile-time error:
error CS0246: The type or namespace name 'IConfigurationSectionHandler' could not be found (are you missing a using directive or an assembly reference?)
This interface is part of the System assembly. I see a reference to this assembly, but it has a yellow exclamation mark icon, and a warning appears in the warnings window:
The referenced component 'System' could not be found.
This is where I ran out of ideas. Am I missing something totally obvious?
I have found the solution. My initial attempt was to install the Microsoft.NETCore package into the console application, resulting in the error shown in my original post.
However, if I install only the narrowly-scoped packages, e.g. System.IO.FileSystem, then I achieve success and the application works correctly. Apparently there is something special about the Microsoft.NETCore "master package" that prevents it from correctly installing into dependent projects.

How to install ajaxControlToolKit.dll in gac

I have two different version dll of ajaxcontroltoolkit in a project, i can not put both in bin folder so i need to install them in gac. How to do it.
In order to add an assembly into the GAC, the assembly needs to be strongly named.
If you have the code, you can do it and then add it to the GAC.
If you don't have the code but the assembly itself, you still can strong name the assembly using the Assembly Linker :
http://msdn.microsoft.com/en-us/library/xc31ft41.aspx
al /out:MyAssembly.dll MyModule.netmodule /keyfile:sgKey.snk
Regards