This question already has an answer here:
signalr unity3d connection
(1 answer)
Closed 11 months ago.
I have a reason to use SignalR in Unity, I have decided to go with Microsoft.AspNetCore.SignalR.Client from NuGet.
I've tried a package Nivot.SignalR.Client.Net35 but it uses AspNet.SignalR.Client which is not used anymore, I have created everything I need on my WebApi solution using Microsoft.AspNetCore.SignalR, then I have changed in my Unity project in PlayerSettings Scripting Tuntime Version .NET 4.x Equivalent and Api Compatibility Level to .NET Standard 2.0, which is compatible with AspNetCore.SignalR.Client.
But after I install the package in visual studio while editing scripts and I try to use it Visual Studio keeps calm, but Unity says That the namespace Microsoft.AspNetCore.SignalR.Client doesn't exists.
I have read that I have to copy them to a folder in the Assets folder, so I did it, and then Unity said "Unloading broken assembly Assets/Packages/Microsoft.AspNetCore.SignalR.Client.dll, this assembly can cause crashes in the runtime" and it doesn't work.
I've lost my hope. But then I remembered that there is Stackoverflow, so now I hope that someone here can help me. Thanks.
You'll have to target .net framework instead of .Net Standard 2.0 in your Unity project because there is no signalr Core out there that targets .Net Standard 2.0 that Unity does. Until Unity updates to 2.2 or 3.0, we're out of luck getting the client side SignalR Core lib working with Unity.
Alternatively, you could try to use a different .net websocket implementation on the client side in Unity.
Your error is related to missing dependencies.
Using the latest stable binaries, SignalR client and server both work in Unity3D. You can find the minimum set of DLLs you need here, in the AspNetCore and AspNetCoreClient1.1.0 directories. Include the associated .meta files. Visit this project's settings for proper configuration.
You cannot use nuget in Unity3D correctly, it is too buggy.
Related
tl;dr:
I have a .NET Framework 4.7.2 project consuming a NuGet package which supports .NET Standard 2.0. That package, in turn, requires another package which supports .NET Standard 2.0. However, when run, the latter package uses net461 binaries rather than netstandard2.0.
How do I force a NuGet package & its dependencies to use .NET Standard 2.0?
Are there special steps required to consume a .NET Standard package from a .NET Framework 4.7.2 project?
Specifics:
I am trying to get the NuGet package for SparkplugNet (which uses the MQTTNet package) working in a .NET Framework 4.7.2 project - just the basic "How to use" SparkplugB example. Both projects support .NET Standard 2.0. After some debugging (details below), it appears MQTTNet is trying to use code paths specific to .NET Framework 4.6.1, rather than .NET Standard 2.0, and crashing with no feedback whatsoever.
To troubleshoot, I built SparkplugNet and MQTTNet from source. As far as I can tell, the crash comes from hitting .NET 4.5/4.6.1-specific code in CrossPlatformSocket.ConnectAsync(), specifically this line (in context):
await Task.Factory.FromAsync(_socket.BeginConnect, _socket.EndConnect, host, port, null).ConfigureAwait(false)
When I debug, _socket is a System.Net.Sockets.Socket which doesn't appears to have a BeginConnect() method, at least in the source file my debugger pulled. I am not sure why it branches to that code when .NET Standard 2.0 would be a better fit.
Back to a 4.7.2 project consuming SparkplugNet & MQTTNet via NuGet package.... If I look at the reference paths, SparkplugNet is properly pointed at the netstandard2.0 folder, but MQTTNet points to packages\MQTTnet.4.1.3.436\lib\net461\MQTTnet.dll. If I change the hint path manually in the project file, MSBuild appears to pull from the netstandard2.0 folder, but it still crashes. I assume it is the same cause, though I'm having trouble debugging using NuGet packages. Also, I'm hoping for a better solution than hacking hint paths.
I have a problem with the HtmlAgilityPack...
I have correctly imported the pack in Visual Studio (References > Manage NuGet Packages > Browse, and just installed the package)
In Unity I get this error:
Assets/Scripts/Searcher.cs(13,7): error CS0246: The type or namespace name 'HtmlAgilityPack' could not be found. Are you missing an assembly reference?
I didn't forgot two add using HtmlAgilityPack; in my script
Using ? :
- Unity 2017.2.1f1
- Microsoft Visual Studio Community 2015
- HtmlAgilityPack 1.6.13
Not sure why this was marked impossible. You can do this by simply dropping HTMLAgilityPack.dll into Unity. Unity will recognize the library and make it available in VS2017.
Here's what it looks like in Unity when imported correctly.
I am on (Experimental .Net 4.6), but I doubt that makes a difference.
Based on a similar question over on Unity Answers:
Unity itself is incapable of handling Nuget packages, they're more of a VS thing. But as long as the assembly targets .NET 2.0 you should be able to use the .dll in Unity without issue
I can't find any information on what version of .NET that HtmlAgilityPack targets, but my guess is that it isn't the same as what Unity uses. By default Unity 2017 uses the .NET 3.5 runtime with an option to switch to the experimental 4.6 runtime.
The best compatibility will be with both targetting the same version, but in the case of it differing, Unity will need to be newer as if the dll uses features added by (say) .NET 4.6 and Unity's set to use .NET 3.5, Unity won't be able to handle those calls.
Try changing to the .NET 4.6 experimental runtime and seeing if that works.
Under Edit -> Project -> Player:
Current .net framework version of Unity is .net v4.6
Will it allow importing of plugins that target .net v4.7?
And as a more generic (not version based) question.
Does Unity allow importing of dlls built on a higher version than the Unity build support?
No.
The reason is that the DLL may have used C# feature that is not yet supported in the current version of Unity. It will fail silently or you will get a similar error below:
The primary reference "The DLL" could not be resolved because it has a
higher version "x.x.x.x" than exists in the current target framework.
The version found in the current target framework is "x.x.x.x".
You need to recompile the plugin with the-same version of .NET Unity is using or find another plugin with the correct version.
This scenario goes a bit against the whole way nuget works so what i might be asking for is a hack...
My problem:
I need to have Restsharp and Protobuf-net referred to in a .net assembly that going into SQL-CLR for Server 2008 (so max .net 3.5, framework 2.0).
Restsharp goes back to 3.5 as the lowest supported fwk version.
Protobuf-net 3.5 onwards has a lot of gunk referring to system.servicemodel (and WCF) which i don't need and use and actively want to remove because it causes issues with installing on SQL-CLR. Protobuf-net 2.0 doesn't have this :)
So i've built and tested my code with an assembly targeting .net 3.5 and i installed the restsharp nuget - which gave me the correct reference and i manually added a reference to the protobuf-net 2.0 distro.
This is where i'd like to know - can i (in any way) install the protobuf-net nuget package but still have it reference the .net20 DLL in my assembly which targets 3.5?
The static reference is not a huge deal since protobuf-net has been pretty stable, but i'd like to get the whole setup via nuget if possible.
In the end, this is a workaround as solution to:
protobuf-net version without system.servicemodel dependency?
If there's a better answer to that, i'd be very grateful :)
As far as I know, that is not possible. You could of course create your own custom build and host it on a local nuget drop, or as your own nuget package on the public feed. AFAIK, there's no way to do what you want inside a new nuget folder in the existing package.
We are using enterprise library 4.1 and smart client software factory 2008 to our application.
how we can upgrade enterprise library 5.0 and SCSF 2010 to our application.presently we are using visual studio 2008.
To upgrade what are the thing needs to be taken care.
Early help would be appreciated.
In terms of Enterprise Library, the best case scenario would be to replace the 4.1 assembly references with 5.0 assembly references and change the configuration (to use 5.0 references instead of 4.1 references). However, you could also hit some issues.
You should read the Microsoft Enterprise Library 5.0 Migration Guide for a full description. The Breaking Changes document could also help you determine if you may run in to migration issues.
For the Smart Client Software Factory the approach appears the same: change the references and configuration to use the new dlls. The Web Client Software Factory 2010 Documentation download has a section on Migrating to Visual Studio 2010.
Install the 5.0 package.
remove all the previous refreneces and add the newer ones generated.
You can refer the dlls by copying it to some folders or directly from the location where you have installed (C:\programfiles\Microsoftenterpriselibrary5.0)
I faced the below issues while migrating
Configuration errors in web.config files - some of my references in the web.config files were refering to the older version(2.0.0.0)(i upgraded from 2.0 to 5.0) and the publictokenkey="null"
so i pushed all the dlls to the gac and added the publicktokenkey from the c:\windows\assembly. which solved the issue
And another issue was regarding the microsoft.practices.enterpriselibrary.caching.cryptography- it was displaying soem weird error.- solution-the bin folder was having the old dlls and when tried to
clean the solution the dll reference was still there. SO i deleted all those from the folder and rebuild again.
IT was initially having the logicacmg.enterpriselibraryextensions.logging which caused some issues- i used the microsoft.practices.enterpriselibrary.logging.configuration.rollingflatfiletracelistenerdata which could solve the issue.
Hope some one might get some inputs with this post