I updated my C# WPF application to use latest versions of NLog and NLog.Extensions.Logging.
It works everywhere except in this VMWare Horizons client where it crashes with this error:
$exception {"Attempt by method 'NLog.Extensions.Logging.NLogLoggerProvider..ctor(NLog.Extensions.Logging.NLogProviderOptions, NLog.LogFactory)' to access method 'NLog.LogManager.get_LogFactory()' failed."} System.MethodAccessException
This project is currently using NLog v4.5.11 and
NLog.Extensions.Logging v1.4
A previous version of my application which uses NLog v.4.4.12 and
NLog.Extensions.Logging v1.0 worked in this VM so i am trying to fall back to that. Then i'll work my way up the versions of these libraries.
More to follow soon... meanwhile, any insight into what might be causing this would be very welcome.
using Microsoft.Extensions.Logging;
using NLog.Extensions.Logging;
using System;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
var loggerFactory = new LoggerFactory();
var Logger = loggerFactory.CreateLogger<Program>();
loggerFactory.AddNLog();
Logger.LogDebug($"============{Environment.NewLine}");
Console.ReadLine();
}
}
}
You have a problem with your deployment. Your application is not using NLog ver. 4.5 (But some older version).
LogFactory-property became public with this: https://github.com/NLog/NLog/pull/2316
Maybe you have old NLog registered in Windows GAC ? (Global Assembly Cache)
Maybe try writing the typeof(NLog.LogFactory).Assembly-location using Console.WriteLine.
I'll add to answer https://stackoverflow.com/a/54557849/8081796
This issue is actual for Windows 8.
Get path to used NLog.dll:
typeof(NLog.LogFactory).Assembly.Location
If the path leads somewhere in C:\Windows\Microsoft.NET\assembly\GAC_MSIL then just delete this file
Thanks Stepan.
As I recall, it is not easy to delete a file from the GAC. And from what I have learned, not a good practice because it could break another application that depended on it.
Windows installer maintains a reference count of items in GAC, increasing the count with each install, reducing with each uninstall. If the count goes to 0, the dll is also removed from the GAC.
I uninstalled the application that put Nlog in the GAC. (It was another application that I had written long ago.) Then i modified the installer for that old app, ensured that it did not put it back in the GAC and re-installed it. And everything was well again.
Related
I have an Elipse E3 Studio (build 5.0.434) server with a bunch of tags (running on a x64 windows) and I want to read then from a .NetCore (3.0) console application (same machine). The thing is Elipse works with COM (as far as I know) and .NetCore can't natively handle it. Gotta use some Interoperability Library or something. .netCore3.0 Release Notes at Windows Native Interop
To make the Elipse server work I used a hardkey so the server was running locally.
I have named my tag "A1" and set the value inside Elipse.
To make the access I made a C# program using e3DataAccessLib and referenced it on the .csprj.
The Program.cs is as follows :
using System;
using E3DATAACCESSLib;
namespace ElipseNetCore{
class Program{
static void Main(string[] args){
try{
E3DataAccessManager e3DA = new E3DataAccessManager();
e3DA.Server = "localhost"; //kinda pointless but still
object Value = new object();
object Timestamp = new object();
object Quality = new object();
e3DA.ReadValue("A1.Value", ref Timestamp, ref Quality, ref Value); //ReadValue is a Elipse Server method that takes in a "tag" and place the result in the ref's
Console.WriteLine($"Value: {Value}, Timestamp: {Timestamp} and Quality: {Quality}");
}//end try
catch(Exception ex){
Console.WriteLine("the mother funking error now is :" +ex.ToString());
//regsvr32 C:\Users\lucas.battistella\Documents\Desenvolvimento\ElipseNetCore\ElipseNetCore\obj\Release\netcoreapp2.2\win-x64\ElipseNetCore.dll
}//end catch try
}//end Main
}//end Program
}//end namespace
The Error I get is the following:
System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {80327130-FFDB-4506-B160-B9F8DB32DFB2} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
Other answers point to a x32 on a x64 or vice-versa issue.
However I've already tried making sure everything is running on x64.
Then I tried everything on x32/x86.
Also tried manually registering the .dll with regsvr32 (as show in the commented out line in the first code block and also the E3DATAACESSLib.dll), got and error popup saying "the said dll was loaded but the entry point DllRegisterServer was not located. Verify if the said dll is a DLL or OCX file"
I've been entangled with this problem for a few days now and since I'm new to all this I don't even know if I'm tumbling in the right direction. I would really appreciate any explanation and please excuse my typos.
How do I retrieve data from an Elipse server? Have I missed something?
UPDATE: I have tried that exact same code on Visual Studio running on .Net Framework 4.7.2 and it worked.
Also tried (still on Visual Studio) on .NetCore and got the aforementioned error.
Work Around:
Forget about NetCore and migrate to NetFramework 4.8. Forget about VSCode and keep rolling with VS.
Every time I look back at this problem it intrigues me. The E3DATAACCESSLib was build against x32 and for NetFramework (which mean Windows necessarily). The weird bit is that it ran on my machine targeting x86 (VS and NetFramework 4.8) but not on VSCode and NetCore. I read conflicting information on libraries built for NetFramework working (or not) on Core.
Today I tried running the built working code on a different machine (virtual and remote) and it showed me the exact same error message. And I fixed it by installing the E3 program and restarting the machine, simple as that.
If that ring any bell to you please share the light.
Are there any restrictions with packages you can use with Azure Functions. I have researched as much as I can and it doesn't seem so, however when I try creating an Azure Function that references the package "Microsoft.ServiceFabric" I get the following error:
System.Private.CoreLib: Exception while executing function:
ScaleDownServiceFabrics. FunctionApp2: Could not load file or assembly
'System.Fabric, Version=6.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific
file. (Exception from HRESULT: 0x80131621). System.Private.CoreLib:
Could not load file or assembly 'System.Fabric, Version=6.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
I have tried both Azure Func and.1 and 2, and .Net Framework and .Net Core with no luck.
using System;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host;
using Microsoft.Extensions.Logging;
using System.Fabric;
namespace FunctionApp5
{
public static class Function1
{
[FunctionName("Function1")]
public static void Run([TimerTrigger("*/5 * * * * *")]TimerInfo myTimer, ILogger log)
{
log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");
FabricClient client = new FabricClient();
}
}
}
Is this possible, or a limitation of Azure Functions in Visual Studio - if so, what packages are acceptable?
ServiceFabric packages are x64 bit, if your function target 32bit it will fail. Try the solution proposed by Jerry Liu
Service Fabric Packages have to be added as packages instead of reference the dll directly in the project, because of the dependencies on other libraries. You should add the NuGet package Microsoft.ServiceFabric.
Microsoft.ServiceFabric latest version 6.3.x targets .Net Standard 2.0 and .Net Framework from 4.5 to 4.7.1, make sure you are using any of these on your project.
Make sure the Microsoft.ServiceFabric DLLs are being copied to the bin folder when built\deployed.
When you use FabricClient outside the cluster, you have to specify the settings and credentials, otherwise you won't be able to connect to the cluster. See this example and this docs.
FabricClient uses Service Fabric API to interact with the cluster, if are having issues with the packages, another option is use HttpClient and make the requests to the API and avoid the packages conflicts
Diego and Suraj have pointed out the cause, conflict between 64 and 32 bit.
Two points to fix
Set build platform to x64 like what you have done.
Get x64 Function runtime. Functions work on Function runtime(contained in Azure Function core tools), but the default bit is x86 downloaded by VS.
To get x64 bit in an easy way, let's use Nodejs to install Azure Functions Core Tools from NPM.
After installation, in cmd input npm i -g azure-functions-core-tools --unsafe-perm true to get Function core tools.
Then set project debug properties(right click on your project>Properties>Debug blade).
Set Launch type to Executable
Set Executable path to %appdata%\npm\node_modules\azure-functions-core-tools\bin\func.exe.
Add Application arguments start.
I run into exactly same issue as #tank140 commented in original post:
Unable to load DLL 'FabricClient.dll' or one of its dependencies: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
More details in another question that I fired on the issue. As answer, it was confirmed that SF Client API for .NET requires that SF runtime is installed on the platform, which is not supported in Azure Functions.
In my case I just update the azure platform configuration to 64 bit. However, I was using .net core 3.1 function app into win platform.
I have a Windows application which captures the details from screen based on the configuration. I am using UI Automation to capture the details from the screen. Everything works fine on the developer's machine where Visual Studio is installed. When I run the same application on another system where we have only .NET Framework 4.5 installed, it started behaving strangely, and it's not able to detect the child element.
My question is why it works fine on the developer's machine where Visual Studio and .NET Framework are installed. What's the difference? Is there anything we are missing as far as prerequisites? Any dependencies of UI Automation or any library we are missing..?
Thanks in advance - please help me out.
It looks like a known bug in .NET wrapper around native UIAutomationCore.dll (yes, its core is not a .NET). And it's included into WinVista+ (.NET Framework also adds it even to WinXP).
Here is a C# example how to use native COM API (UIAutomationCore.dll) from C#. Just copying the code here:
using System;
using interop.UIAutomationCore;
namespace PrintDesktopUiaElementNameViaCom
{
class PrintDesktopUiaElementNameViaComProgram
{
static void Main(string[] args)
{
// Instantiate the UIA object:
IUIAutomation _automation = new CUIAutomation();
// Get the root element
IUIAutomationElement rootElement = _automation.GetRootElement();
// Get its name
string rootName = rootElement.CurrentName;
Console.WriteLine(
"The root automation element's name should be 'Desktop'.");
Console.WriteLine("The actual value is: '{0}'", rootName);
}
}
}
Yeah at last after doing day's reading, i came to know the solution is that der is no dependency on Visual studio.
This behavior is due to lack of privileges to the application. so to overcome this behavior we have to get signed our application and one more thing its very important thing is place your executable file in Program Files
Reference Links : https://msdn.microsoft.com/en-us/library/windows/desktop/ee671610(v=vs.85).aspx
Trying to automate WHQL testing using the ONE AND ONLY document available on the subject: http://www.microsoft.com/whdc/devtools/wdk/dtm/dtm_dsso.mspx
I've played with the example code and am able to connect, list devices, etc. From there I've created a new project, a .NET 2.0 C# class:
using System;
using System.Reflection;
using System.IO;
using CookComputing.XmlRpc;
using Microsoft.DistributedAutomation.DeviceSelection;
using log4net;
class WhqlXmlRpcService : XmlRpcService
{
private static readonly ILog Log = LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);
public static DeviceScript deviceScript;
[XmlRpcMethod("connect")]
public Boolean Connect(String dtm)
{
Boolean retVal = false;
deviceScript = new DeviceScript();
try
{
deviceScript.ConnectToNamedDataStore(dtm);
retVal = true;
}
catch (Exception e)
{
Log.Debug("Error: " + e.Message);
}
return retVal;
}
}
I'm using XML-RPC.NET to create a server that is hosted by IIS (using ASP.NET 2.0). The DTM Studio is installed in C:\Inetpub\wwwroot\xmlrpc\bin, the same place where the target of my class goes, to assure there are no resolution issues with the dozen or so .dll's I reference (as instructed by the DSSO doc). I tried adding the necessary DSSO libraries to the GAC to avoid this, but not all of them have strong names. So, despite being able to see all the libraries it needs to link against (and the Studio app functions just fine installed in a non-standard location), attempting .ConnectToNamedDatastore("nameofDTM") still results in the following:
xmlrpclib.Fault: <Fault 0: 'Could not connect to the controller to retrieve information. Several issues can cause this error including missing or corrupt files from the installation, running the studio application from a folder other than the install folder, and running an application that accesses the scripting APIs from a folder other than the installation folder.'>
I'm accessing the scripting APIs from the installation folder, as it's the same dir as my web service .dll, and the files aren't corrupt, because if I stick an .exe with the DSSO sample code in that same directory I can see it connect just fine in the debugger.
I'm at the end of my rope with this, and have been unable to find a helpful source for DTM/DSSO info anywhere.
Anyone done anything similar in the past, or had any success automating their WHQL testing?
I was unable to get this to work using an ASP.NET web service .dll, however, I was able to access the DSSO API by making my XML RPC server available using the HttpListener class in .NET. If you deploy the target application into the same directory as DTM Studio, all works as expected.
For an example of how to use XML-RPC.NET with HttpListener, see:
http://www.cookcomputing.com/blog/archives/000572.html
Note: "ListenerService" has been incorporated into the latest versions of XML-RPC.NET since the time of the linked post above. It can be found under CookComputing.XmlRpc.XmlRpcListenerService
I have a program that works fine on VS2008 and Vista, but I'm trying it on Windows 7 and VS2010 / .NET Framework 4.0 and it's not working. Ultimately the problem is that System.Diagnostics.PerformanceCounterCategory.GetCategories() (and other PerformanceCounterCategory methods) is not working. I'm getting a System.InvalidOperationException with the message "Cannot load Counter Name data because an invalid index '' was read from the registry."
I can reproduce this with the very simple program shown below:
class Program
{
static void Main(string[] args)
{
foreach (var pc in System.Diagnostics.PerformanceCounterCategory.GetCategories())
{
Console.WriteLine(pc.CategoryName);
}
}
}
I did make sure I'm running the program as an admin. It doesn't matter if I run it with VS/Debugger attached or not. I don't have another machine with Windows 7 or VS2010 to test it on, so I'm not sure which is complicating things here (or both?). It is Windows 7 x64 and I've tried forcing the app to run in both x32 and x64 but get the same results.
It seems performance counters were corrupted on my system. Although I didn't follow this post exactly, it led me to the solution. Here is what I did:
In an command prompt with administrator/elevate privileges typed the following:
lodctr /?
Useful stuff in there...
Then typed:
lodctr /R
According to the docs from the prior step, this gets windows to rebuild the perf registry strings and info from scratch based on the current registry settings and backup INI files. I have a feeling this is what did the magic. However, next I noticed the .NET performance counters were not there anymore so based on this I typed the following to reload them:
lodctr "C:\Windows\Microsoft.NET\Framework64\v4.0.20506\corperfmonsymbols.ini"
Note that this path is for .NET Framework 4.0 on x64. You can imagine the path for other variations of the framework/platform. I'm guessing you should always load the counters from the highest version of the .NET framework that you have installed, but that is just a guess.
I hope this helps someone else someday!