Could not load file or assembly 'SuperSocket.SocketEngine' or one of its dependencies. The system cannot find the file specified.

[thomaslevesque]

I used this NuGet package, which seems to be the most recent. The package doesn't contain SuperSocket.SocketEngine.

Here's the stack trace:

at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName, ObjectHandleOnStack type)
   at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName)
   at System.RuntimeType.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
   at System.Type.GetType(String typeName, Boolean throwOnError)
   at SuperSocket.SocketBase.AppServerBase`2.SetupBasic(IRootConfig rootConfig, IServerConfig config, ISocketServerFactory socketServerFactory)
   at SuperSocket.SocketBase.AppServerBase`2.Setup(IRootConfig rootConfig, IServerConfig config, ISocketServerFactory socketServerFactory, IReceiveFilterFactory`1 receiveFilterFactory, ILogFactory logFactory, IEnumerable`1 connectionFilters, IEnumerable`1 commandLoaders)
   at SuperSocket.SocketBase.AppServerBase`2.Setup(IServerConfig config, ISocketServerFactory socketServerFactory, IReceiveFilterFactory`1 receiveFilterFactory, ILogFactory logFactory, IEnumerable`1 connectionFilters, IEnumerable`1 commandLoaders)

And the fusion log from the exception, if it helps:

=== Pre-bind state information ===
LOG: DisplayName = SuperSocket.SocketEngine
 (Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: SuperSocket.SocketEngine | Domain ID: 1
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///[redacted]/bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : SuperSocket.SocketBase, Version=1.6.5.0, Culture=neutral, PublicKeyToken=6c80000676988ebb.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: [redacted]\bin\Debug\MyApp.vshost.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///[redacted]/bin/Debug/SuperSocket.SocketEngine.DLL.
LOG: Attempting download of new URL file:///[redacted]/bin/Debug/SuperSocket.SocketEngine/SuperSocket.SocketEngine.DLL.
LOG: Attempting download of new URL file:///[redacted]/bin/Debug/SuperSocket.SocketEngine.EXE.
LOG: Attempting download of new URL file:///[redacted]/bin/Debug/SuperSocket.SocketEngine/SuperSocket.SocketEngine.EXE.

Apparently SuperSocket.SocketBase needs SuperSocket.SocketEngine (although there's no explicit reference), but SuperSocket.SocketEngine has a reference to SuperSocket.SocketBase... How is this all supposed to work?

Anyway, adding the SuperSocket.Engine package solves the problem. I think the SuperSocket.WebSocket package should have a dependency on SuperSocket.Engine, not SuperSocket

[Lillecarl]

Confirmed

[kerryjiang]

There is another package you need use: SuperSocket.Engine

[thomaslevesque]

There is another package you need use: SuperSocket.Engine

Yes, as I said in the issue description ;)

What I'm saying is that if this package is necessary, it should be a dependency of the SuperSocket.WebSocket package, so that it's added automatically.

[vspin]

With resolve, #24 can most likely be closed as well.

[Eucly2]

You can find all binaries here : http://supersocket.codeplex.com/releases/view/618113

[thomaslevesque]

You can find all binaries here : http://supersocket.codeplex.com/releases/view/618113

Who cares about binaries when there's NuGet? :wink:

[Eucly2]

I agree. But I had the same problem and I found this solution... I hope this will be temporary and superwebsocket will work fine with NuGet ^^

PS: Sorry for google trad

[electronik54]

is this issue fixed? i still have this issue.

--UPDATE--

ok, just had to add a reference SuperSocket.Engine

i totally missed kerryjiang's comment above, but it should have been added automatically if its so important.

[zdenek-horak]

Additionally, I had to follow this in order to get SuperSocket.Engine dll's propagates into output directories of referencing projects.

[rahamath18]

Need to install SuperSocket.Engine.

[thomaslevesque]

Need to install SuperSocket.Engine.

Need to read previous comments 😉

[Lillecarl]

I don't see why this package doesn't depend on supersocket.engine if it's required. The point of nuget is to manage dependencies.