I'm trying to use WCF Data Services and a little confused what library should I reference to interact with WCF Data Services: Microsoft.Data.Services.Client.dll or System.Data.Services.Client.dll.
What is the difference between them? In which case should I use each of them?
When trying to add references to both of them I get a compiler error:
The type
'System.Data.Services.Client.DataServiceContext'
exists in both 'e:\Program Files\WCF
Data Services Mar 2011
CTP2\bin.NETFramework\Microsoft.Data.Services.Client.dll'
and 'e:\Program Files\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Data.Services.Client.dll'
System.Data.Services.Client.dll is part of the base framework that ships with .NET 3.5 and upwards. The Microsoft.Data.Services.Client.dll is an updated version of this library (from your directory paths I see you're using the March 2011 CTP) which is not yet part of the base .NET installation package and contains any new features since the base release.
So if you're looking to use some of the latest features include the Microsoft dll. If you're just after base functionality (that will be 100% supported by anything with the proper .NET framework installed) use the System dll.
Here's a blog article outlining the difference between the Microsoft and System namespaces:
http://blogs.msdn.com/b/brada/archive/2008/11/16/what-does-that-net-namespace-mean-system-and-microsoft.aspx
If you do need to use system.data.services and system.data.services.client, make sure to explicitly remove the microsoft variants i.e. right-clicking references -> right click and remove the microsoft ones.
Related
My ultimate goal here is to install the correct SQLite package in Visual Studio 2019 on a Windows 7 SP 1 64 bit
The project is a WinForms app and I might try UWP apps
It seems the NuGet Ice Cream Store has a lot of flavors of SQLite
System.Data.SQLite 1.0.113.1
The official SQLite database engine for both x86 and x64 along with the ADO.NET provider.
This package includes support for LINQ and Entity Framework 6.
System.Data.SQLite.Core 1.0.113.1
The official SQLite database engine for both x86 and x64 along with the ADO.NET provider.
sqlite 3.13.0
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. This package contains native libraries for SQLite on Linux, macOS, and Windows (desktop and Universal Windows apps).
The Last option here seemed like the correct and logical choice then I looked at this SO Post
SO LINK
After 3 days of reading and searching I have given up hence the confusion has won
While I stated my ultimate goal above can I also assume NuGet will put the SQLite package in the project Reference Folder
The question is I want to have a self contained EXE project once packaged
The last one was last updated almost 4 years ago, so clearly not the right option. That was from before Microsoft embraced SQLite as it's recommended file-based database system. Microsoft used to provide its own SQL Server CE but presumably decided that there was no point trying to compete withy SQLite as it already did what .NET developers needed. Notice that the new options start with System.Data, which is generally reserved for Microsoft's own types.
As for the other two, if you check the dependencies for each you will see that the first has a dependency on the second. As the descriptions say, they are both the official SQLite database engine and ADO.NET provider but, unlike the Core package, the first adds support for LINQ and EF6. Do you want that support? That is what determines which package to add.
If you don't know which you need then you can just add the Core package for now and add the other later if you need it. Also be aware that NuGet packages are added on a per-project basis. Even within the same solution, projects can have different packages added. You should/will add just the packages needed for each project you create.
I'm having a problem with assembly resolution on an end-user machine and I believe it's related to using Portable Class Libraries....
I have a .NET 4.0 application that was originally written in Visual Studio 2010. Recently we upgraded to Visual Studio 2012 and we've created a few projects that are Portable Class Libraries. I don't believe we need these features now, but we're also building a Windows 8 Store application that might benefit from these libraries.
When I compile my project, what exactly does the portable library feature do? I expect that it allows me to run it on different frameworks without modification or recompiling.
When I look at the library in reflector dotPeek it shows the Platform attribute as:
.NETPortable,Version=v4.0,Profile=Profile5
And the references seem 2.0-ish:
mscorlib, Version=2.0.5.0
System, Version=2.0.5.0
System.Runtime.Serialization, Version=2.0.5.0
When I run the application on this end-user's machine, I see an error in the log file:
Could not load file or assembly, 'System.Core, Version=2.0.5.0...'
Googling System.Core 2.0.5.0 seems to refer to SilverLight -- which appears to be one of the targeted frameworks.
This machine does not have Visual Studio installed, but has .NET 4.0 (4.0.3 update)
Is there something I should be doing differently to compile, something I should investigate in my dependencies or something I should be looking to install on the end-user machine? What does the 2.0.5.0 refer to?
For .NET 4, you need an update (KB2468871) for Portable Class Libraries to work. From the KB Article:
Feature 5
Changes to the support portable libraries. These changes include API
updates and binder modifications. This update enables the CLR to bind
successfully to portable libraries so that a single DLL can run on the
.NET Framework 4, on Silverlight, on Xbox, or on the Windows Phone.
This update adds public Silverlight APIs to the .NET Framework 4 in
the same location. The API signatures will remain consistent across
the platform. All modifications are 100 percent compatible and will
not break any existing code.
Also see the "Deploying A .NET Framework App" section of the MSDN Portable Class Library Documentation.
EDIT: Actually, if the machine has .NET 4.0.3 installed as you mention, that should be sufficient. Can you double-check to make sure that it is actually installed?
I have a CLR project that calls a simple HTTP web service. Its x64-targeted and I got it to serialize properly only after going through the steps outlined at the following link which talks about the changes required to have VS2010 point to the correct target architecture (x64) - the changes just required unloading and changing the .csproj file with a few extra lines to reference the correct version of sgen.exe: http://geekswithblogs.net/akraus1/archive/2011/12/10/148002.aspx
Now, I am able to build this project and its .XmlSerializers.dll by setting "Generate serialized assembly" to on. I wanna do this because my CLR project is going to get deployed on the database, and I don't want it to runtime serialize any objects since those DLLs are not referenced in my database and I don't want to give my CLR project permissions higher than EXTERNAL_ACCESS for security reasons because this will be used in a production environment where security is important, and also because my database is NOT trustworthy.
Long story short, I am following the guide at the following link to upload my serialized assembly into the database but I get an error: http://footheory.com/blogs/bennie/archive/2006/12/07/invoking-a-web-service-from-a-sqlclr-stored-procedure.aspx
The error is: CREATE ASSEMBLY for assembly '.XmlSerializers' failed because the assembly is built for an unsupported version of the Common Language Runtime.
Does anyone know how to correct this by forcing sgen.exe to serialize a CLR-supported version of the assembly? Viva the Stack.
SQL Server 2005/2008/2008R2 supports only .Net 2.0. You need to change your project to target this, see How to: Target a Specific .NET Framework Version or Profile. You do not need to specify x64 for the build target, SQLCLR assemblies should be Common target built.
That said, calling web services from SQLCLR is a really really really bad idea. Don't do it. Have an external process handle the HTTP calls.
I found that the problem was actually not the fact that I'm using .NET 3.5 as a target, but I was referencing the wrong version of the sgen.exe tool, which in this case I needed the x64 version of 6.0A (which translates to .NET 3.5) at this path: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\sgen.exe. Now I am able to build the correct version of the serialization assembly, upload it, and also use it.
I've installed mono 2.10 along with monodevelop and have used monodelveop to code some apps under ubuntu. Several of these apps needed to access to the JavaScriptSerializer, which is part of the System.Web.Script.Serialization namespace.
In order to be able to instantiate and use a JavaScriptSerializer, I had to add a reference to my app in monodevelop - but I see there appear to be two packages that I can chose from: one named "system.web.extensions" and the other named "mono".
If I use the first package (system.web.extensions) I get a runtime error when using the JavaSerializer. I tried using the "mono" reference instead and it works fine.
So far so good. But now, I want to run this same app under windows and I'm getting a "cannot load assembly" error for System.Web.Exceptions.
I'm confused at this point: Why are there two packages shipped with mono/monodevelop for some of these assemblies, and which one(s) should I be using in order to be cross-platform?
Thanks!
Michael
Why are there two packages shipped with mono/monodevelop for some of
these assemblies?
Mono assemblies are kinds of internal assemblies: they provide additional features, not included in the .NET Framework. The System assemblies rely sometimes on these (i.e. Mono.Web for ASP.NET Web services).
Which one(s) should I be using in order to be cross-platform?
Always use the System ones. The Mono assemblies are not available under .NET Framework (unless you ship them manually).
Mono 2.10 provides two versions of the System.Web.Extensions assembly: 1.0.61025.0 and 4.0.0.0. Be sure to use the 4.0 version.
If the problem persists, could you post your code? (for me, no problem using the JavaScriptSerializer)
I am building an executable using VS2008 and .NET compact framework 3.5, targetting Windows Mobile 6 professional, but whenever I compile the project, everything that I have specified in the AssemblyInfo.cs file is ignored.
I have done this many times in other projects and it works without problem, but for some reason I cannot get the AssemblyTitle/AssemblyProduct/AssemblyVersion attributes etc to show up (I am trying to view them using Windows Explorer, I am able to see these properties in the details tab for any other assembly that I have built - even other projects in the same solution).
Any suggestions?
That info is looking at the native version info, which on the desktop is set using the AssemblyFileVersionAttribute. The AssemblyFileVersionAttribute is unsupported in the CF, so the only way to set the version info out of the box is to command-line compile. There is a workaround in this blog.
I know this is old, but there's a simpler solution posted here:
Version number in .NET Compact Framework application
You have to use reflection.
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Major System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Minor System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Build System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Revision
in tag PlatformFamilyName; rather that PocketPC, change to add WindowsCE
in csproj