I'm creating a little Silverlight LOB app. I created the app + web in Blend 4 and I've opened the solution in VS2010 to add the WCF service. When I do so, it shows an error on using System.Linq;. It says:
The type or namespace name 'Linq' does not exist in the namespace 'System'(are you missing an assembly reference?)
I had VS2010 create the WCF service and I've tried to re-add the reference in for .NET 4 System.Core.dll.
So newbie dev question... What did I do wrong :)
Check in the references if you DO see the System.Core.dll assembly.
If you do not see it, add it manually.
It should be in C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll (or in Program Files (x86) if your OS is x64).
After recompiling it should then work.
Related
I'm having issues adding a service reference to my WPF project in VS2017. The service itself is a WCF Data Service using EntityFramework (EntityFrameworkDataService). In VS2013 that I was using before, I didn't have any issues adding services to my WPF project. I upgraded to VS2017 last month, and recently made some changes to the WCF service and needed to refresh the reference in my WPF project. I couldn't seem to get it to refresh so I deleted the reference and started trying to re-add the reference and now I'm greeted with this error message:
The specified OData API cannot be added because OData APIs are now
only supported with Connected Services.
For more information, please see:
https://aka.ms/odatavsclientguidance
That provided link does not have any info regarding VS2017 setups. It recommends to use the 'OData Connected Service' extension but that extension does not support VS2017 (tried it but got a "not compatible" message). I also found the 'VS WCF Connected Service' extension for VS2017, but it doesn't appear to support WPF projects (or atleast I couldn't figure it out).
Has anyone ran into this issue with adding a WCF Data Service reference to a WPF project? Any other suggestions that I could try?
I typically generate my clients via the DataSvcUtil.exe which is part of the .net framework
e.g.
"%windir%\Microsoft.NET\Framework\v4.0.30319\DataSvcUtil.exe" /dataservicecollection /version:2.0 /language:CSharp /out:c:\temp\DataService.cs /uri:http://localhost:16584/DataService/
The MSDN docs:
https://msdn.microsoft.com/en-us/library/ee383989(v=vs.110).aspx
As TGRA so eloquently stated, the best bet for VS2017 at time of writing is to use the dataserviceutil.exe. To make things simpler for myself I do the following:
In File Explorer, navigate to the datasvcutil.exe using the path as follows:
%windir%\Microsoft.NET\{{YOUR_PROCESSOR_ARCHITECTURE}}\{{YOUR_FRAMEWORKVERSION}}
Hold shift and right-click. Select Open Commandwindow here (or command prompt if you prefer.
Now execute a datasvcutil.exe command like so for C#: datasvcutil /language:Csharp /out:{{PATH_TO_PROJECT}}/{{SERVICE_NAME}}.cs /uri:{{URL_TO_SERVICE}}.svc
OR execute a datasvcutil.exe command like so for Visual Basic: datasvcutil /language:VB /out:{{PATH_TO_PROJECT}}/{{SERVICE_NAME}}.VB /uri:{{URL_TO_SERVICE}}.svc
And voila, you're done.
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.
I've got this error that I just can't figure out.
I'm using VS 2012 (VS11) on Windows 8 with .net4.5 and I get this error when compiling a project that worked with VS 2010 and .net4.0.
This is the full error:
The type System.Windows.Input.ICommand exists in both 'c:\Program
Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\PresentationCore.dll'
and 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.dll'
If anybody could provide some insight on what is causing it and/or how to fix it I'd be grateful.
Thanks.
c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.dll
The message is accurate, ICommand indeed exists in both assemblies for .NET 4.5. The problem is your reference to System.dll, your project is using the wrong one. The assemblies in the Microsoft.NET directory are no longer suitable to act as reference assemblies, like they were in versions of .NET prior to .NET 4.0. They should no longer be there but unfortunately are required to get C++/CLI projects built.
Your reference to PresentationCore.dll is correct, it uses the c:\program files\reference assembly subdirectory. The proper home for reference assemblies in .NET 4.0 and up. These assemblies are special, they contain only metadata and are not a copy of the runtime assemblies.
You'll need to fix your project. System.dll is probably not the only assembly that has this problem. Open the References node of your project and verify them one by one. Remove bad ones that point to Microsoft.NET and replace them with good ones by using Project + Add Reference. Best to just replace them all to be sure.
I had a similar problem with fxcopcmd V12.
I was able to solve it by explicitly adding
/reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\WindowsBase.dll"
See: FxCop engine exception on WPF assembly
Take a look at this similar post, How can I resolve this? The unit type exists in two dll files, it suggests that you are referencing two assemblies with the same type, so you would need to give the type you want to use the fully quantified name.
We had the same problem with our libraries after moving to a new build server.
The solution was to specify the path of the .net framework to build against:
/p:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
If the .net 4.0 framework (Multi-Targeting Pack) is not installed on the build server (as it was with us), you can just copy the "v4.0" folder with all its assemblies to the build server ;)
I'm currently working on an Xbox360 game. In this game I have lots of data stored in XML. Deserializing it through IntermediateSerializer in the XNA Game project is no problem, works like a charm. But since these structures stored in XML can be quite complicated I decided to make a simple editor for the stuff, so I (or maybe a less experienced user) could edit the objects visualy (animations, game stages etc) rather than having to write these data as XML. Then I would serialize it through the IntermediateSerializer and everything would be fine.
For this editor I created a WPF project, and referenced the Microsoft.Xna.Framework.Content.Pipeline.dll
Visual Studio recognizes the IntermediateSerializer class, and intellisense helpfully recommends to use the Microsoft.Xna.Framework.Content.Pipeline.Serialization.Intermediate namespace, but I keep getting the following error message:
The type or namespace name 'Pipeline' does not exist in the namespace 'Microsoft.Xna.Framework.Content' (are you missing an assembly reference?)
(I'm using XNA 4.0 and .NET 4)
Am I doing something wrong or is this just simply impossible?
Tenshiko
In your Application Properties ensure
that the Target framework is set to
.NET Framework 4.
By default a new WPF application targets the .NET Framework 4 Client Profile. The Client Profile is designed to reduce the download size of the .NET Framework for end users and excludes assemblies that are only used in development. In your case Microsoft.Xna.Framework.Content.Pipeline.dll depends on Microsoft.Build.Framework and Microsoft.Build.Utilities.v4.0 which are not available in the Client Profile.
It seems to me that you did set a target framework of your WPF application to ".NET Framework 4". It has to help.
Sketchflow newbie (couple days), WPF newbie (few weeks).
Workspace details:
WinXP, Visual Studio 2010 Ultimate, Expression Studio Ultimate (using Expression Blend 4 with SketchFlow). Downloaded the Sketchables 0.9 release and built a release version (Debug version is already built).
Issue details:
Start up Expression Blend 4, create a WPF Sketchflow project. Build it (successful). Add references to either the release or debug versions of the Sketchables library (in the Desktop, rather than the SL folder) and try to build again. The build fails with error:
Unknown build error, 'Could not load file or assembly 'System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXX' or ore of its dependencies. The local assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'
Now, I've seen some issues with a similar error, specifically a couple of issues where the problem was caused by trying to load a Silverlight control in a WPF project. However, I'm not knowledgeable enough to know if it's related. On a hunch, I tried a Silverlight project. Sure enough, building a Silverlight Sketchflow project and adding the Sketchables library builds cleanly.
So, the question is this: Does anyone have any ideas about what's actually causing this error within the Sketchables source, on pointers on how to track it down so I can work on it and get a clean library build for WPF?
Chuck's right. The Sketchables.Common dll is a Silverlight class library. Easy way to fix is to create a Sketchables.Common.WPF project and make it a regular class library. Copy over the classes from the SL library project, compile, and then change the reference in Sketchables.WPF to point to Sketchables.Common.WPF instead of Sketchables.Common. Your Blend project should now build.
A more advanced way is to share both Common projects to same files, but I won't go into that here. Search for share (link) files between projects and you'll find answers for that.
You have identified the cause of the problem, the assembly you are trying to reference in your WPF project was compiled for Silverlight (the 2.0.5.0 version number is a giveaway that it is Siverlight).
You might want to check with the author of the controls to see if there is a way to compile it for WPF.