I'm using Rx Framework version 1.0.10621 (Rx-Main and Rx-WinForms) installed over nuget within an Windows forms application and I can't find the method CreateWithDisposable<T>()!
Where is it? Which namespace or dll?
It was removed as part of the "christmas" release.
The same functionality is available in the Create() overloads
Related
I have created a VS2013 solution that contains multiple projects. One of those projects is a portable class library targeting .NET 4.5+, Silverlight 5, Windows Store 8+ and Windows Phone 8 and this project contains a reference to an OData service in an accompanying web application.
The portable class library references Microsoft.Data.Services.Client.Portable (among others), added via nuget (WCF Data Services Client).
I have then added the portable class library to a WPF (.NET 4.5) application, a Windows Store application and a Windows Phone application and written some very basic test code to access the service. This works fine in Windows Store and Windows Phone.
The WPF application however will not compile. The errors are...
The type 'System.Data.Services.Client.DataServiceContext' is defined
in an assembly that is not referenced. You must add a reference to
assembly 'Microsoft.Data.Services.Client.Portable, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The type 'System.Data.Services.Client.DataServiceQuery`1' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Microsoft.Data.Services.Client.Portable, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The thing is, I also added the WCF Data Services Client to the WPF application via nuget, but it does not add a reference to the portable library (packages\Microsoft.Data.Services.Client.5.6.0\lib\portable-net45+sl5+wp8+win8\Microsoft.Data.Services.Client.Portable.dll), instead adding a reference to the full framework 4.0 version (packages\Microsoft.Data.Services.Client.5.6.0\lib\net40\Microsoft.Data.Services.Client.dll) - which in turn is causing the error I am seeing.
Is there something I am doing wrong here or is this an error in the installation package? Note that if I delete the offending reference and add the alternative reference manually then all is well so though I have a work-around I would still like to know if I am the cause of the error.
Looking at the NuGet source code this behaviour seems to be by design.
The WCF Data Services Client contains assemblies for the following frameworks:
.NET Framework, v4.0
.NET Portable, net45, sl5, wp8, win8
Silverlight, v4.0
Installing this NuGet package into a project that targets .NET 4.5 will result in the .NET 4.0 assembly from the NuGet package being referenced. NuGet considers the more specific .NET framework to be a better match for your WPF project which targets .NET 4.5.
There is a comment in the NuGet source code about this when it looks for the best matching assembly in the NuGet package.
// Let's say a package has two framework folders: 'net40' and 'portable-net45+wp8'.
// The package is installed into a net45 project. We want to pick the 'net40' folder, even though
// the 'net45' in portable folder has a matching version with the project's framework.
Though TPL is widely accepted as a feature of C# 4.0 , but heard that it is not supported on SL4, but SL5.
Could not find any solid evidence of it.
So why the do MicroSoft implemented a feature in WPF but not Silverlight, though both sl4 and wpf4 released around same time.
If you need TCL in Silverlight 4 you can add the "Microsoft.Bcl" and "Microsoft.Bcl.Async" nuGet packages to your project.
They implement part of what TCL delivers in .net.
More info can be found here
Don't forget you have to use the TaskEx class instead.
Hoped it helped.
We have a Silverlight 5 project and we currently have a folder of shared library DLL's. We are in the process of changing to use NuGet for these libraries wherever possible.
One of the NuGet packages we want to use is MVVMLight, to replace the MVVM Light SL4 DLL's we are currently using, which were never upgraded when we moved from SL4 to SL5.
However, when we installed the NuGet package containing the SL5 DLL's it automatically changed our existing references to the Microsoft.Practices.ServiceLocation DLL file to one which came with the MVVM Light package, which has the same version number, but a different public key.
This has caused a conflict with some of our other code which is using the Prism library, which uses the Microsoft.Practices.ServiceLocation DLL, but, signed with the original public key.
Obviously we cannot use the same named DLL twice in the same folder, so, any suggestion on how to resolve this issue, whilst keeping both Prism and MVVM Light packages installed from NuGet.
Thanks very much,
Martyn.
I have exactly the same problem with Microsoft.Practices.ServiceLocation.dll. In my case, this could be resolve if the nuget package of MvvmLight was dependent of CommonServiceLocator as I suggested here : http://mvvmlight.codeplex.com/discussions/429311
So far, no news about that.
Edit : Laurent just push a version of MVVM Light using the CommonServiceLocator from Nuget.
The Portable.CommonServiceLocator NuGet package contains the existing signed CSL binaries as well as the PCL one that supports windows 8, .net 4.5 and others. Still waiting on Microsoft to include the PCL in their official package, but the binaries are the same in the one I mentioned.
You can also try using Portable.MvvmLightLibs, which is a PCL version. That one supports all of the frameworks (WP7.5+, .NET 4.5, Store, SL4+) and uses the official Microsoft-signed CSL libraries.
Given that Silverlight uses a cut down .net framework, can I reference Unity from a Silverlight project?
There is a special version of Unity for Silverlight which you ou can donwload from here. (If you use nuget it will reference the correnct dlls for you automatically)
However Unity for Silverlight has some restrictions:
XML configuration is not supported.
Because of differences in the Silverlight security model, only public types can be created and injected by the container. The desktop version allows you to also inject internal types.
The Unity interception mechanism is not supported.
Note that (thanks the info to #Sebastian Weber) Interception is also supported since the release of EntLib Silverlight Integration Pack. See MSDN for additional information.
But you can't use the Unity "desktop dlls" in your SL project.
It exist a special version of Unity for Silverlight. You can find it here
The latest version is 2.1 and is supported for Silverlight 3-5
I am running some tests on Selenium Web Driver. But looks like that I need some dlls like WebDriver.Common.dll, WebDriver.Firefox.dll.
I had downloaded the web driver api from this link
http://code.google.com/p/selenium/downloads/detail?name=selenium-dotnet-2.1.0.zip&can=2&q=
And when I unzip, could not find the dll that I mentioned in the subject.
I am using Visual Studio 2010 & creating a class library.
Please let me know if there is another link to download the mentioned dll or another way to get this working.
WebDriver.Common.dll, WebDriver.Firefox.dll, and all of the other browser-specific assemblies were combined into a single WebDriver.dll assembly for the final 2.0.0 (and later) releases. You should only have to create a reference to WebDriver.dll to be able to use all of the functionality of the Selenium WebDriver API.
Another helpful step to point out is adding the proper using statements for each driver type.
For Example:
using OpenQA.Selenium.Firefox;
using OpenQA.Selenium.IE;
using OpenQA.Selenium.Chrome;