VS2010 beta 2 can't build MG files? "error 0000: Cannot resolve type with name 'MarkupExtension'"

Question

Hi,

I hope this is the proper place to post this. I realise it could be taken as a VS question, but the problem (and stack trace) seem to point to Oslo as the culprit.

In a nutshell, when I try to build a project with a .mg file in it in VS2010 beta 2, I get the error:

C:\Program Files (x86)\MsBuild\Microsoft\M\v1.0\Microsoft.M.Embedded.targets(138,5): error 0000: Cannot resolve type with name 'MarkupExtension' and namespace 'http://schemas.microsoft.com/winfx/2006/xaml'. Multiple CLR types found with the same name and namespace. Please check the type names and XmlnsDefinitionAttribute declarations to ensure that XAML type names are unique.

 

The same project built fine in VS2010 beta 1.

I tried a completely clean project file, added the mprice.mg file from this article:
    http://msdn.microsoft.com/en-us/library/dd441702.aspx

Then made the changes to the project file described here:
    http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/c8563030-1c70-47b1-8bfc-4bc9c638c2b4

And the same problem happened. (It's nice that it wasn't my code that was the problem, but...)

If I run MSBuild on it directly, outside of VS2010, I get an exception and stack trace:

ExecuteM:
  Compiling to obj\x86\Debug\mprice.mx
     at Microsoft.M.Driver.DriverBase.Compile(TargetType target, CompilerOptions compilerOptions)
     at Microsoft.M.BuildTask.MCompilerDriver.Run()
     at System.Xaml.ClrTypeResolver.FindTypeInNamespace(XamlNamespaceRecord namespaceRecord, String typeName, XNamespace typeNamespace, Int32 genericArgumentCount)
     at System.Xaml.ClrTypeResolver.ResolveUserType(XName typeName, Int32 genericArgumentCount)
     at System.Xaml.ClrTypeResolver.TryResolveType(XName typeName, Int32 genericArgumentCount, Type& type)
     at System.Xaml.ClrTypeResolver.TryResolveType(TypeReference typeReference, ISchemaTypeResolver schemaTypeResolver, Type& type)
     at System.Xaml.XamlSchemaTypeResolver.RegisterClrType(TypeReference typeReference)
     at System.Xaml.XamlSchemaTypeResolver.Resolve(TypeReference typeReference)
     at System.Xaml.XamlValidatingReader.PopulateSchemaTypeHierachy(SchemaType type)
     at System.Xaml.XamlValidatingReader.FindMemberForType(String memberName, SchemaType type)
     at System.Xaml.XamlValidatingReader.CaptureStartMember()
     at System.Xaml.XamlValidatingReader.InRecord.HandleMember(XamlValidatingReader reader)
     at System.Xaml.XamlValidatingReader.ReaderState.Read(XamlValidatingReader reader)
     at System.Xaml.XamlValidatingReader.Read()
     at System.Xaml.XamlValidatingReader.ReadToEnd()
     at System.Xaml.XamlObjectDeserializer.XamlNavigator..ctor(ISchemaTypeResolver schemaTypeResolver, XamlObjectDeserializerSettings settings, XamlReader reader)
     at System.Xaml.XamlObjectDeserializer.Load(XamlReader xamlReader, XamlObjectDeserializerContext context)
     at System.Xaml.XamlServices.Load(XamlReader reader)
     at System.Xaml.XamlServices.Load(XmlReader reader)
     at System.Xaml.XamlServices.Load(TextReader reader)
     at System.Xaml.XamlServices.Load(Stream stream)
     at System.Dataflow.DynamicParserFactory.GetParser(IList`1 parts, String parserName)
     at System.Dataflow.DynamicParserFactory.GetParser(Package package, String parserName)
     at System.Dataflow.DynamicParserFactory.LoadFromStream(Stream stream, String parserName)
     at Microsoft.M.Parser.SourceParser.<>c__DisplayClass3.<CreateDynamicParserHelper>b__0()
     at Microsoft.Internal.LazyInit.Init2[T](T& itemToInit, Func`1 lazyCreator)
     at Microsoft.Internal.LazyInit.Init[T](T& itemToInit, Func`1 lazyCreator)
     at Microsoft.M.Parser.SourceParser.CreateDynamicParserHelper(String parserName, DynamicParserFactory& factory, DynamicParser& dynamicParser)
     at Microsoft.M.StandardLibrary.StandardLibraryCreator.Parse()
     at Microsoft.M.StandardLibrary.StandardLibraryCreator..ctor()
     at Microsoft.M.StandardLibrary.<Create>b__0()
     at Microsoft.Internal.LazyInit.Init2[T](T& itemToInit, Func`1 lazyCreator)
     at Microsoft.Internal.LazyInit.Init[T](T& itemToInit, Func`1 lazyCreator)
     at Microsoft.M.StandardLibrary.Create()
     at Microsoft.M.SemanticGraph.SymbolResolver..ctor(IEnumerable`1 images, Boolean includeStandardLibrary)
     at Microsoft.M.SemanticGraph.SemanticGraphImporter..ctor(IEnumerable`1 images, Boolean includeStandardLibrary)
     at Microsoft.M.Compiler.SemanticAnalyzeSchema(CompilerOptions options, CompilationResults results)
     at Microsoft.M.Compiler.SemanticAnalyze(CompilerOptions options)
     at Microsoft.M.Driver.DriverBase.Compile(TargetType target, CompilerOptions compilerOptions)
  ---Inner Exception Details---
C:\Program Files (x86)\MSBuild\Microsoft\M\v1.0\Microsoft.M.Embedded.targets(138,5): error 0000: Cannot resolve type with name 'MarkupExtension' and namespace 'http://schemas.microsoft.com/winfx/2006/xaml'. Multiple CLR types found with the same name and namespace. Please check the type names and XmlnsDefinitionAttribute declarations to ensure that XAML type names are unique.

It's this stack trace that makes me think this is the right place to post the question.

So, am I doing something wrong, or is there a problem with building MGrammar files under .NET 4? If there is, how do I fix it?

Cheers,

    Geoff

Answer 1

Beta 1 and Beta 2 have different versions of the CLR. You'll probably have to wait for a new release of Oslo before it will be compatible with the new version. 

Answer 2

Justin is correct--there are some differences between the .NET 4 betas that we've been resolving for the next CTP. It's been necessary to wait until Beta 2 is finalized to thoroughly test the Oslo bits against it. Thanks for your patience in the matter.

.Kraig

Answer 3

My current project uses WF4 and MGrammar. The problems with WF4 meant I had to upgrade to beta 2 to get it working. But that means the MGrammar part no longer compiles. So it looks like I can have workflow or M, but not both. That's very frustrating.

Can you tell me if it's purely a compilation problem, or if it's a runtime issue as well? I could compile the MGrammar file into a .NET 3.5 DLL to get around the compilation issue, but that's not going to help if the problem is more fundamental than that.

Any other workarounds also appreciated!

Cheers,

Geoff

Answer 4

Hello Geoff,

I'm having the same problem as you, even thou i have not been able to solve it yet. It seems like the MetaSharp project on codeplex (http://metasharp.codeplex.com/ ) has.

This is what i'm looking at for the moment, check it out and see if it can help. And please post the solution if you have found one =)

Best Regards

Markus

Answer 5

Unfortunately I think the problem is that the Beta1 version of Oslo uses .net 4.xx while the Beta 2 bits use 4.yy, meaning it's not just as simple as switching to .net 3.5 for compilation, it's as if you don't have .net4 installed at all. Normally this isn't an issue because a product typically targets a released version of the runtime which is always available but with oslo, since it's totally alpha/beta/whatever the runtime it's working against is more of a moving target. Unfortunately I think you're stuck with either:

1.) waiting until the next release of Oslo.

2.) create a VPC or another machine that will let you install VS 2010 Beta 1

Answer 6

Oh and btw, MetaSharp suffers from the same issues :( you have to have VS beta 1 and the latest oslo bits to build it / run it.

Answer 7

I'm no further on, I'm afraid. I hoped it was a build issue, but I built it from the command-line and embedded the MX, and it then failed at runtime.

Are you sure MetaSharp has solved the problem? I can't find any information on it in the source control comments.

Cheers,

    Geoff

Answer 8

Unfortunately I think the problem is that the Beta1 version of Oslo uses .net 4.xx while the Beta 2 bits use 4.yy, meaning it's not just as simple as switching to .net 3.5 for compilation, it's as if you don't have .net4 installed at all. Normally this isn't an issue because a product typically targets a released version of the runtime which is always available but with oslo, since it's totally alpha/beta/whatever the runtime it's working against is more of a moving target. Unfortunately I think you're stuck with either:

1.) waiting until the next release of Oslo.

2.) create a VPC or another machine that will let you install VS 2010 Beta 1

Hi,

Thanks for that. I did build it from the command line and then embedded the resultant MX, but at runtime I got the same error:

System.InvalidOperationException : Cannot resolve type with name 'MarkupExtension' and namespace 'http://schemas.microsoft.com/winfx/2006/xaml'. Multiple CLR types found with the same name and namespace. Please check the type names and XmlnsDefinitionAttribute declarations to ensure that XAML type names are unique.
at System.Xaml.ClrTypeResolver.FindTypeInNamespace(XamlNamespaceRecord namespaceRecord, String typeName, XNamespace typeNamespace, Int32 genericArgumentCount)
at System.Xaml.ClrTypeResolver.ResolveUserType(XName typeName, Int32 genericArgumentCount)
at System.Xaml.ClrTypeResolver.TryResolveType(XName typeName, Int32 genericArgumentCount, Type& type)
at System.Xaml.ClrTypeResolver.TryResolveType(TypeReference typeReference, ISchemaTypeResolver schemaTypeResolver, Type& type)
at System.Xaml.XamlSchemaTypeResolver.RegisterClrType(TypeReference typeReference)
at System.Xaml.XamlSchemaTypeResolver.Resolve(TypeReference typeReference)
at System.Xaml.XamlValidatingReader.PopulateSchemaTypeHierachy(SchemaType type)
at System.Xaml.XamlValidatingReader.FindMemberForType(String memberName, SchemaType type)
at System.Xaml.XamlValidatingReader.CaptureStartMember()
at System.Xaml.XamlValidatingReader.InRecord.HandleMember(XamlValidatingReader reader)
at System.Xaml.XamlValidatingReader.ReaderState.Read(XamlValidatingReader reader)
at System.Xaml.XamlValidatingReader.Read()
at System.Xaml.XamlValidatingReader.ReadToEnd()
at System.Xaml.XamlObjectDeserializer.XamlNavigator..ctor(ISchemaTypeResolver schemaTypeResolver, XamlObjectDeserializerSettings settings, XamlReader reader)
at System.Xaml.XamlObjectDeserializer.Load(XamlReader xamlReader, XamlObjectDeserializerContext context)
at System.Xaml.XamlServices.Load(XamlReader reader)
at System.Xaml.XamlServices.Load(XmlReader reader)
at System.Dataflow.Languages.MImageBase.LoadXaml(PackagePart part)
at System.Dataflow.Languages.MImageBase.GetPartData(IPackagePartDescription partDescription)
at Microsoft.M.MImage.LoadMGrammarPart()
at Microsoft.M.MImage.get_ParserFactories()

 

Unfortunately, the Workflow problem (and subsequent wait for beta 2) has held things up so long that I can't afford to hang around until whenever the next beta of Oslo is. And creating a VPC for VS2010 beta 1 won't work here because it's the same process that runs the (beta 2 required) Workflow code. If I run that under beta 1, Workflow fails, if I run it under beta 2, MGrammar fails.

So it looks like I don't have any realistic alternative but to look for a replacement for MGrammar for this project. Any suggestions?

Cheers,

    Geoff

Answer 9

I think you can use ANTLR in .net:

http://www.antlr.org/

Also the Gold Parser:

http://www.devincook.com/goldparser/

Answer 10

Nice! I was just looking at the ANTLR site, since it was the only alternative I'd heard of before. Going to check out GOLD Parser now!

Cheers,

    Geoff

Answer 11

It seems as this is a know bug in VS2010 beta 2, others have reported similar behaviour.
I tried to get around the problem with MCompileTask by having compiled it in vs2008 and then doing:

var image = MImage.LoadFromResource(Assembly.Load(AssemblyFileName), ResourceFileName)

That kind of solved the MCompile problem for me (at the moment).
The next issue came instead when referencing Microsoft.M.dll and System.DataFlow.dll in vs 2010 beta 2.

C:\Windows\Microsoft.NET\Framework\v4.0.21006\Microsoft.Common.targets(1291,9): warning MSB3258:
The primary reference "System.DataFlow, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"
could not be resolved because it has an indirect dependency on the .NET Framework assembly
"Microsoft.Build.Framework, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
which has a higher version "3.5.0.0" than the version "2.0.0.0" in the current target framework.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=459230&wa=wsignin1.0

No workaround that i know of yet...

/markus

Answer 12

Well that's interesting, if it's purely a CLR issue I'm surprised you're seeing these errors... maybe you can solve it then.

Answer 13

Both of these tools use a more traditional BNF grammar, but their API's are not as .net friendly as MGrammar. They should be extremely fast. Oh and here's another...

Irony:

http://www.codeplex.com/irony

Answer 14

My current project uses WF4 and MGrammar. The problems with WF4 meant I had to upgrade to beta 2 to get it working. ...

Cheers,
Geoff

Maybe obvious but, just in case, have you look further (forums or others) for a WF4 workaround that may allow you to keep using BETA1? - as a way cross-off all possible option.

[If you already have then please ignored]

Hope this helps,
-Jaime.

---

-Jaime.

Answer 15

Maybe obvious but, just in case, have you look further (forums or others) for a WF4 workaround that may allow you to keep using BETA1? - as a way cross-off all possible option.

Heh, I'd love to, I really, really would! I described the problem over on the WF4 forum over two weeks ago:
    http://social.msdn.microsoft.com/Forums/en-US/wfprerelease/thread/fe284256-c830-405d-b863-55a316613111

So far, no-one has answered. I suspect it's partly because Persistence changed so significantly for beta 2, and that's been their focus, so they don't want to investigate issues with a beta 1 Persistence issue when that code is effectively 'dead' now. In any case, the WF4 bug appears before any of my code is run, and with no source code it could take me weeks working through the problem with Reflector to find its cause.

On a brighter note, ANTLR is pretty awesome. Not as .NETty as MGrammar, but for my simple use it may be OK.

Cheers,

    Geoff

Answer 16

You got a reply on the link you sent, you may want to reply explaining the reasons why moving to BETA2 is not a good option....

Hope this helps,
-Jaime.

---

-Jaime.

Answer 17

Hi,

Thanks for that. I've just replied on that thread. I've bitten the bullet and ditched all the Oslo code in my current project, and moved to beta 2. I need working workflow more than I need working MGrammar at the minute, and the MGrammar part was easier to replace.

Cheers,

    Geoff