Im trying to use the WCF Data Services Toolkit together with Microsoft WCF Data Services March 2011 CTP 2 for .NET Framework 4 and Silverlight 4. But When i use this release i get multiple compile errors regarding missing reference to System.Data.Services. Of course i can't reference that assembly, since i already reference Microsoft. Data.Services and will get alot of "multiple types" error. To me it seems like WCF toolkit has been compiled against the System.Data.Services that ships with .Net 4 and the compiler needs a reference even though im not using any types from that assembly.
So how on earth is Jonathan Carter in the MIX 11 session able to reference only Microsoft.Data.Services and use the toolkit without any compilation errors?
As expected, the answer is to recompile the source yourself against the CTP binaries.
http://wcfdstoolkit.codeplex.com/workitem/13
I ended up doing that myself, after watching and rewatching the MIX11 session a thousand times following whatever Jonathan did down to the last detail.
Related
Since VSTO has yet not been ported to .NET Core, can I do it the old fashioned way and create a unmanaged shim to load the CLR and host the managed .Core 5 add-in?
My particular use case is an Outlook COM add-in that is currently built using VSTO against .NET framework 4.7 but I want to start leveraging .NET 5. In terms of interaction with Outlook, it just adds some buttons on the Ribbon and makes a few calls into the Outlook object model. I don't need to do anything like VSTO document based add-in in Excel for example.
I don't want to down the JS path as there is quite a bit of C# code that would need to be ported.
I found this https://github.com/jozefizso/COMShimWizard/releases which shows how to do it with the .NET framework, and am assuming its pretty close if not identical to what the shim wizard did back in VS 2010.
Since I need to load .NET 5 I believe to load the CLR I will need to do something along the lines of what is outlined here: https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting.
Before I dig further into it, is the approach likely to work? In particular, will in be possible to do necessary COM gymnastics to instantiate the managed components?
And assuming all this is feasible, will this be more or less equivalent to what VSTO does for .NET framework 4.x, i.e. is it less safe or performant in any way or will there be any functionality that won't be available compared with an add-in built with VSTO?
Update 1
I did some more research which raised some additional potential issues.
For the .NET framework case, once a class has been loaded into the CLR it is relatively easy to "unwrap" the returned reference to get a COM pointer which can be used to access COM interfaces that the type implements. It is not clear to me how this can be done when loading the .NET Core runtime using netfxr interface.
.NET Core does not have the concept of app domains, does that mean the multiple add-ins loaded into the Core runtime would not be isolated, or there a way to achieve some degree of isolation? From what I have read it seems that maybe their heaps would at least be isolated but I'm not sure.
Update 2
From reading this https://github.com/dotnet/runtime/blob/main/docs/design/features/COM-activation.md it seems that in Core, requests to types in assemblies as COM servers will result in auto loading the Core runtime (if it isn't already loaded) and create the object in a separate AssemblyLoadContext so maybe a shim is not needed at all? On the other hand it seems that if the Core runtime is already loaded and the version does match what is required by type you are trying to create, then the type will fail to load, so that seem to be a problem...
I ask this because I have been chasing down a co/contravariance issue in SL4. I asked it twice in SO and got answers along the lines of - "It just works, make sure you are using .net 4". I tried my failing code (and the samples people posted) in SL4 and .Net 4 and the results are different (work in .net fail in sl). So is SL4 actually running on a < 4 version. Or are there just some features left out (accidentally or on purpose). If so what features
What about SL 5?
The core compiler in Silverlight 4 supports Covariance and Contravariance, but the framework interfaces (ie: IEnumerable<T>) unfortunately were not marked as covariant (note in the docs that it isn't IEnumerable<out T> as it is in .NET 4).
Silverlight 5 fixes this, "officially" supporting Covariance and Contravariance.
I have a Silverlight 4 project that contains some business objects. I added a Test project. One of the tests is to serialize the business objects from the Silverlight project using DataContractSerializer. To reference DataContractAttribute, I have to add a reference to System.Runtime.Serialization. However, there are different and apparently incompatible versions in the Silverlight runtime and in the .NET 4 Runtime of the Test project.
What's the best strategy to serialize objects in a Silverlight project such that they can be consumed by a standard .NET 4 runtime?
For this purpose i would use the DataContractJsonSerializer. This serializes your business objects to json. It it supported in Silverlight and .NET Framework since 3.5.
An example how to use the serializer can be found here.
If your objects allow it (regarding constraints mentioned below), try a serializer such as protobuf-bet or one of the other protocol buffer implementations.
http://code.google.com/p/protobuf-net/
They place some constraints on the implementation of your business objects (contracts, rather), for example that null and empty collections are considered equivalent to name one example.
I realized this morning that I had added a reference to a Silverlight project from a non-Silverlight project and VS warned about that not being a good idea, but still allowed the non-Silverlight project to run. Because a different version of System.Runtime.Serialization was referenced in each project, the unit test aborted with an inability to load that DLL.
I've been doing some research on finding an embedded database to be used with Silverlight/isolated storage. Everyone says SQLite will not work with Silverlight due to unmanaged code.
From my experience there is just a dll named System.Data.SQLite.DLL which I believe I either got from installed SQLite.NET or from the NHibernate build.
When configuring in c# code you can use a file based database and just specify a file to use.
So my question is where is the unmanaged code? And why wouldn't using file based database and writing it to isolated storage work? And now that Silverlight 4 supports OOB does that have any impact on this?
Answers appreciated ahead of time.
Regards
I'm not sure what features you need, but you might also want to check out Sterling
Sterling is a lightweight
object-oriented database
implementation for Silverlight and
Windows Phone 7 that works with your
existing class structures. Sterling
supports full LINQ to Object queries
over keys and indexes for fast
retrieval of information from large
data sets.
Here is the introduction blog post about this project.
Note: At the time of this post Sterling has not been released. You can download the source code though.
SQLite as downloadable from sqlite.org is written in ANSI-C (see the features page). That's what most people are thinking of when you say "SQLite" and it's definitely unmanaged code.
System.Data.SQLite.DLL appears to be "An open source ADO.NET provider for the SQLite database engine" and is "a complete drop-in replacement for the original sqlite3.dll (you can even rename it to sqlite3.dll if you're using it natively)" which seems pretty cool.
However, reading on, I see "The desktop native SQLite library and the ADO.NET wrapper are combined into a single mixed assembly" which seems to be saying that the DLL contains both managed and unmanaged code, which may be a problem.
There is no ADO.Net in Silverlight 4
I heard from a friend that Microsoft rewrote all the Windows Workflow Foundation (WF) again and changed everything was in .Net 3.5.
Is that true?
And what about what we learned about WF in 3.0 and 3.5?
According to this article:
http://visualstudiomagazine.com/articles/2009/01/01/windows-workflow-changes-direction.aspx
Windows Workflow Foundation 4.0 is a "bottom-up rewrite with entirely new thinking...WF 3.0/3.5 will remain part of the framework and will run side by side with WF 4.0. This lets you manage the transition at a time that fits your organization's broader goals."
...which is code for, "We know we just screwed up your programming model, but we have a long term strategy, so we hope you will forgive us."
The article goes on to say that
The gains are enormous: custom
activities take center stage, and
authoring them is much simpler;
workflows are entirely declarative;
and there are three workflow flow
styles that you can combine
seamlessly. It's possible that you
could see a 10-fold improvement in the
time required to create and debug
workflows, in addition to 10- to
100-fold runtime performance
improvements.
The change is not without its detractors. In this article at DotNetKicks, the author states that "Microsoft is seriously damaging the Dot Net developer community and adoption in the industry with these half baked product releases and abrupt about-faces after shipping."
Which is why I generally wait for the 2.0 or 3.0 version of Microsoft technologies, although I made an exception for ASP.NET MVC.
We found the workflow product to be difficult to wrap your head around when it came time to pass data in and out. Scott Allen had a series of articles that did a good job describing the process, but still this was not at an easy task.
That's what the word on the street is. And on the internet. 3.0 and 3.5 will be deprecated, but still available.
Is this change not in Visual Studio 2010 beta 1? Download it, find out, and tell Microsoft what you think of it.