I've encountered a very bizarre bug that I've narrowed down to a specific scenario but due to potential impact I need to try and find out why.
Application A v 1.0 built for .NET 4.7.2 runs fine on Windows Server 2012 R2
Application A v 2.0 also built for .NET 4.7.2 but now using a .Net Standard 2.0 shared library suddenly causes the tcp stack to fail (specifically all DNS resolution fails, even internal destinations)
This bug only occurs on 2012 R2. 2016 works just fine.
This bug occurs even if only the assembly for the shared library is included, no actual instances declared or references made, not even a using statement, just having the shared library in the dependencies causes this.
Outside of the application DNS resolution works fine.
FusionLogs are functionally identical between what gets loaded on my Windows 10 machine and what gets loaded on 2012 R2. Only difference being the encoded folder names for the native images loaded.
Here's a list of all relevant dependencies from the shared library
BouncyCastle.Crypto v 1.8.5:
Org.BouncyCastle.Crypto.Parameters;
Org.BouncyCastle.OpenSsl;
Org.BouncyCastle.Security;
Common.Logging v 3.4.1:
DnsClient v 1.2.0:
Microsoft.CSharp v 4.7.0:
Mimekit v 2.4.1:
NewtonSoft.Json v 12.0.1:
System v 4.0.0.0:
System.Collections.Generic;
System.Collections.Concurrent;
System.IO;
System.IO.Compression.FileSystem;
System.Drawing;
System.Numerics;
System.Runtime.Serialization;
System.Net;
System.Net.Http;
System.Net.Http.Headers;
System.Security.Cryptography;
System.Text;
System.Threading;
System.Threading.Tasks;
System.Xml;
Exception:
17:16:21 [1] [Info] - DNS Query against 'google.com'
Unhandled Exception: System.Net.Sockets.SocketException: No such host is known
at System.Net.Dns.GetAddrInfo(String name)
at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
at System.Net.Dns.GetHostEntry(String hostNameOrAddress)
at DNSAPITestApp.Tester..ctor() in ...
at DNSAPITestApp.Program.Main(String[] args) in ...
I've searched extensively online however there's just too much white noise of similar DNS issues that still having nothing to do with this specific scenario or why this could be happening (and just as importantly how to confirm any theories).
Any help would be greatly appreciated. I can't post much of the code but if there are any specific areas where a particular dependency is used that anyone would like to see I can add snippets.
Credit for Answer goes to CoolDadTx over at MSDN
The library name is the issue. When you compile that library it is DnsApi.dll. That happens to be the same name as the Windows DLL that contains the DNS native logic. When it tries to load the system DLL it will find yours, because it searches the app directory first and then tries to use it but, of course, it doesn't work.
Rename the class library to something else and try again.
Related
I've got an Azure Function app that creates a precompiled DLL (so it uses normal .cs files, not the older .csx method, pre-VS2017). Previously, it was targeting .Net Framework 4.5.2. I updated it to 4.7 so as to use some of the new C# 7 features. I updated my NuGet packages by doing "Update-Package -Reinstall" and verified that they all have the "net47" target set in my packages.config file.
Everything compiles fine. But when I call a function that uses either of 2 HttpRequestMessageExtensions methods, I get an exception. One example of the exception is this:
Method not found: 'System.Net.Http.HttpResponseMessage
System.Net.Http.HttpRequestMessageExtensions.CreateResponse(
System.Net.Http.HttpRequestMessage, System.Net.HttpStatusCode)'.
Here's an example of a tiny test function that will cause the error:
using System.Net;
using System.Net.Http;
public static HttpResponseMessage Run(HttpRequestMessage req)
{
return req.CreateResponse(HttpStatusCode.Accepted, "");
}
Upon calling this function with say Postman, I'll receive the aforementioned exception. I also get a similar method not found exception when I call GetQueryNameValuePairs() on the HttpRequestMessage.
I've tried updating my NuGet packages to the latest, no difference. I've cleaned and rebuilt and restarted a bunch of times, making sure to nuke my bin and obj directories.
I'm not sure what could be the problem. I guess I could downgrade back to .Net 4.5.2 but I'd rather not. For one, I want to use C# 7, and for two, I want to understand what the problem is rather than avoid it.
Update: interesting. The issue seems to be with System.Net.Http. If I lower it to 4.0.0 everything works fine. If I raise it to any higher version I get the issues listed above. I tried selectively lowering each of my packages, one by one, to their previous version number to find this out. I then updated all but this one to the latest version and it fixed the issue.
I also tested it on my side. The issue is related to the latest version of System.Net.Http assembly(4.3.2). If I don't install this package manually or install the earlier versions(4.3.1/4.3.0), the application could work fine.
The CreateResponse method is a extension method which is written in System.Web.Http assembly(version 5.2.3). It seem that it is not compatible with the latest version of System.Net.Http. Please could just skip the error by using the earlier version of System.Net.Http and you can also submit this issue to Microsoft using follow channel.
https://connect.microsoft.com/VisualStudio/Feedback
Interesting. For me, if I got above version 4.0.0 (including 4.1.1 or 4.3.1) I still get the same problem of not finding those extension methods.
The assembly might not be updated during you change the package version. From the bin\Debug\net47 folder, we could check the current assembly version we used.
If the modified date of assembly is 2/9/2017, the package version is 4.3.1. If the modified date of assembly is 4/19/2017, the package version is 4.3.2. If the assembly is not the latest version, it could work fine on my side.
In addition, Microsoft.Asp.Net.WebApi.Client package is installed by default when creating an Azure function. System.Net.Http is one of its dependencies. So we don't need to install the System.Net.Http package manually. When running our application, NuGet will choose a right version of System.Net.Http for our application.
I had the same issue running my Azure Function locally and eventually tracked it down to conflicting System.Net.Http assemblies. I created my Azure function from a blank ASP.NET Web App and initially pulled down the System.Net.Http NuGet package to use within the project. I also pulled down the Microsoft.AspNet.WebApi.Client for use within the project. It did not matter which version of System.Net.Http I tried my project would compile but fail when the request was made.
Eventually, I removed packages I had downloaded, cleaned the build folder and added just the Microsoft.AspNet.WebApi.Client. I noticed that this automatically referenced the System.Net.Http on my machine for my version of the .NET Framework. (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework). This compiled successfully and I was able to make requests to the function without any exceptions.
Using #Aaron-Newton's insight, I identified that my issue was due to my Azure Functions project referencing a .Net Standard 2.0 class library. I switched it to .Net Framework 4.6 and it started working again. Seems like this is a bug in the Functions tooling.
I've filed a bug with the Functions team here: https://github.com/Azure/Azure-Functions/issues/477
I had the same issue. I spent quite a while to fix this problem.
The cause is that the Azure Functions project is refering to .Net Standard Library with version higher than 1.4.
Bringing down your .Net Standard version to 1.4 or lower would fix the problem.
But this is defintely a bug with Azure Functions SDK. They should fix it.
https://github.com/Azure/azure-webjobs-sdk-script/issues/980
https://github.com/Azure/Azure-Functions/issues/477
We we trying to create a work flow dll using Windows Work Flow but we are running into major problems regarding referencing.
1.) We have a class that calls an activity but the class cannot pick up the activity that has already been created
WorkflowAcivity workflowActivity = new WorkflowActivity(string id)
This then throws an error message saying cannot find WorkflowActivity
2.) We then added extra assemblies, like one of our other dll's, Visual Studio also cant find these references when we call a class in those dll's we are referencing.
3.) Intellisence has also stopped working??
What do we do to fix this, is it the version we are using or are there any other assemblies we are missing here??
We have tried opeing the solution on another pc, uninstalled vs 2012 and installed vs 2013 and still have no luck!
Got caused by System.Net.Http.Primitives.dll referencing some dll's that were missing and caused the workflow to break without any warnings.
Removing this dll or adding the referenced dlls back in (System.Runtime.dll and System.Runtime.InteropServices.dll) fixed the problem.
Microsoft ticket for this.
I tried without success to get a SharePoint 2013 application page or web part to work with Entity Framework 6 (6.0.1 to be exact - the version installed into Visual Studio 2012 by default using NuGet at time of writing).
My code was very simple for test purposes, just reading data from one table.
I could install the package just fine, create models, see that the they were properly configured etc, no problem - but whenever I tried to load the page I got the error:
Event code: 3008
Exception type: ConfigurationErrorsException
Exception message: An error occurred creating the configuration section handler for entityFramework: Could not load file or assembly 'EntityFramework' or one of its dependencies. The system cannot find the file specified. (C:\inetpub\wwwroot\wss\VirtualDirectories\[sitename]\web.config line 36)
I copied all of the config settings from the App.Config file in VS (created by the EF install), into the web.config, verbatim.
I tried every suggested fix I could find on the interweb (e.g. changing the EF assembly ref to "Specific version = false", changing version refs in the config file to the specific version... all sorts) but nothing worked.
I created a console app using the same settings and it worked fine, so I know it's not a server-specific issue - looks like a compatibility issue with SP2013, anyone have any ideas?
I installed EF 5 using the NuGet console, and finally got it working with that... but I'm very curious as to why EF 6 refused to play ball.
Thanks
Poolio
You need to deploy the Entity Framework assemblies (EntityFramework.dll, EntityFramework.SqlServer.dll) as part of your SharePoint solution package. You can reference external dlls in the package.
My Unmanaged VC++ MFC (No .NET used, No CLR support, Use MFC in shared DLL) application trying to deploy with visual C++ runtime files as private assemblies.
It is properly running on windows 7 fresh installed computer.
But I gives “This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.” error in fresh installed wondows XP sp3 computer.
I checked in application event logs. But there also no more details, just showing the same error.
Then I read these threads and surf around the internet.
Thread - 1
Thread - 2
Article -1
But couldn't find any solution clue or trouble shooting method. so here looking for some assist.
The easiest way to test is to install depends on the computer. Most likely, your application is built to use a later version of C++ runtime libraries, e.g. <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.4053' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />, but on the XP system it is an older version.
You would need to check what version of the runtime library used by analysing the program's manifest. Then check what depends is showing.
If the required version of runtime is missing, distribute it with the program's install.
On the side note, you could consider switching to the static link. The size of the binaries will be bigger, but these type of problems will be gone
Hopefully this is a simple one and I'm doing something stupid. I have a web app on .Net 4.5 in VS 2012 which at some point invokes a method which in turn sends a message to a Service Bus in Azure. A service running locally then retrieves this message and processes it. Great.
However, I consistently get exceptions (VS set to break on unhandled) which give the familiar file load exception on Microsoft.ServiceBus.dll version 1.6.0.0, the versions on the machine are 1.7.x.x or 1.8.x.x. I can successfully send and receive messages so I'm not sure what impact this is having! but it only occurs when invoking service bus calls through the very useful RetryPolicy class via the ExecuteAction method in the Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling namespace. I can only assume that this component is built against 1.6.0.0 but I appear to have the latest version.
Has anyone else experienced this issue and how best to work around it? Is it wise to run two versions of Microsoft.ServiceBus? ie. 1.6.0.0 for the cloud service and 1.7/1.8.x.x for the web application? Where can I get 1.6.0.0?
The Windows Azure SDK 1.6 contains Microsoft.ServiceBus.dll 1.6 (that's the November 2011 release). You can get it from here
Now, are you certain that the EnterpriseLibrary is looking for that specific version? In the past (I don't recall exactly when), the SB assembly was added to the GAC when installing the SDK, so perhaps the library is expecting the SB assembly to be GACced. You might want to use fusion logs to validate this before using a year+ old version of the Service Bus dll.