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.
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 can't seem to figure out how to get F# TypeProviders to work in a Windows Store (C#) app.
As far as I can tell, TypeProviders can only be used in an assembly targeting the full .NET Framework, whereas Windows Store apps must target .NET Portable.
I have created an F# assembly and referenced the F# TypeProviders library, however when attempting to reference this assembly from my Windows Store app, I receive an error stating that the library could not be referenced.
Is there any way around this? I want to use F# TypeProviders to reference various data sources and then use the generated code/types in my Windows Store app. Anyone have experience with this?
UPDATE:
Just to be clear, I am asking if there is a way to use the standard F# TypeProviders (such as WsdlService) in a Windows Store App?
Looking at the other assemblies FSharp.Data.TypeProviders.dll is referencing, I don't think there is a way around this. Since most type providers are used for accessing a database in one way or another (ADO.NET, LINQ to SQL, EF), it references System.Data.dll which is not available in WinRT.
The only data sources supported by built-in type providers that can be used in WinRT are web services and OData services. Their type providers maybe could be supported in a WinRT project if they were implemented in a separate library, but not in their current implementation.
Type providers are design/compile time facility. It should work in Portable library profile. It is maybe dependent on how is type provider library implemented, but in general, it should work.
For more info see F# type providers with Portable Library
We are working on SOA, both on client (Silverlight) and server (WCF) sides, but with possibility of the clients being implemented by 3rd parties (.NET, Java, etc.). We use WSDL-first approach and want our data and services interface classes (C#) to be automatically generated from schemas during build process. So we need common data classes code not being regenerated for every service for successful compilation.
I have tried the svcutil utility, trying to first create all data contract classes from XSDs with the /dataContractOnly switch, and compile them to separate class library - the first stage. And then to create each service interface code, omitting the classes already in the library, with the /reference switch - the second stage.
The problem is that our schemas do not meet the DataContractSerializer requirements, so svcutil cannot create data classes. Even after I used xsd utility for this purpose, I cannot use svcutil's /reference switch on the second stage, since this switch only works for DataContract classes. And this is not the case with the classes generated by xsd utility.
So, am I missing something with these tools and are there any way to use them in my situation, or are there any other tools to generate data classes and service interfaces from XSD and WSDL schemas, in case where common data types are used by several service interfaces? Or should we hardly limit ourselves with DataContract compatible schemas? What approach do you use for WSDL-first development?
Have you tried WCF.blue tool by codeplex?
WSCF.blue is a toolset that facilitates the development of web services using a contract first (specifically, a schema first) approach. This is the WCF version of the orginal Web Services Contract First tool.
Also, there is a beautiful article on Contract-First development:
http://msdn.microsoft.com/en-us/magazine/ee335699.aspx
Yes WSCF.Blue is a VS plugin as it ships but the source is available and so it can be rebuilt into a command line interface version like what we had to do, with little effort required I might add.
I'm migrating my solutions from .NET 2.0 to .NET 4.0. I open the solution file in VS 2010 and follow migration wizard.
While building the solution and comparing the changes with the server copy (since solution is under source control VSTS), I surprisingly found that
1) the public classes were changed to 'internal' and
2) the 'public static' properties were changed to 'internal static'
It gave me problem because the output assembly is referred in other projects.
Can someone explain why does it happen? Also, are there any other such changes taking place behind the scene? Or Am I doing something wrong ?
(Note: I have ReSharper 5.1 installed but I think it has no place in this case.)
ReSharper may have given the suggestion to make methods static for those methods which are not using any instance variable or method within it. This is what I have observed.
Similarly, if the methods are not accessed from any other project/assembly, it may give you suggestion to make them internal.
I am very new to VB.net. I have written these objects in VB6 before. I'm just lost in VB.net, but (kicking and screaming) I have to learn how to do this. I've been googling for hours with only minor steps forward. Can anyone post a link that explains start to finish how to do this?
I have managed to write the class object, What I can not tell is how to register it and where the name1 and name2 in the CreateObject("Name1.Name2") come from.
Regsrv32 will not work. It says "Entry Point not found" and will not register it. Also, I can not drop it into the Assemblies directory. I read something about a regasm command one uses, but I can't seem to make this work either.
Thanks in advance for any assistance.
I am going to assume you are not trying to write a COM DLL but rather a complete project that call various sub assemblies like a VB6 EXE call a ActiveX DLL. If you can be more specific about what you are trying to do it would help me better.
Several points about VB.NET versus VB6.
1) For .NET only projects there is no registration. If a EXE or DLL references another .NET DLL the only requirement is that the DLLs be present in the parent's directory.
2) You can do a COM style registration for .NET apps only by registering the .NET assembly in the GAC. However there are several requirements for doing this. Do a search on the .NET GAC and it will give you the scoop on how to do this.
3) You can setup the .NET assembly to use COM in which case it will operate by the rules of COM including registration with regsvr.
You will find for .NET only project that #2, or #3 only come in rare instances. #1 will apply for 90% of your DLL assemblies. Of This is dependent on your project.
A common use for CreateObject is allow for plug-ins or installable libraries. .NET handles this through the Reflection API. With the reflection API you can look in a directory, go through each .NET DLL and see what them and create objects from what you find. Search for .NET Reflection to read up on this.
If your project is .NET only then I recommend that you create a Assembly that is reference by both the master assembly and the individual sub assembly that define the interfaces of the objects you are creating. This when you use the reflection API and determine the Object type you can assign it to a variable of that interface and code it noramlly with intellisense and other aids.
if you have old COM ActiveX Controls or DLLs .NET will generate a wrapper class that exposes the ActiveX Objects to .NET. I would spend some time learning how .NET does this. What I do create a dummy project and have .NET reference the ActiveX stuff I need. I then find the wrapper projects and DLL it made and move them into a central area. That why when I work on subsquent projects using the same ActiveX stuff I know where all the wrappers are.
You have to go to your class library properties and select the option "Register for COM interop". This will make your assembly available to COM.
You want to create what's called a COM Callable Wrapper (aka CCW) for your .NET component. This basically entails setting up some COM interfaces with some GUIDs and either enabling "Register for COM Interop" in the project properties (as mentioned) or using regasm.exe.