New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xaml Type Provider does not work with assembly-internal controls #159

Closed
rojepp opened this Issue Nov 26, 2012 · 4 comments

Comments

Projects
None yet
3 participants
@rojepp
Contributor

rojepp commented Nov 26, 2012

When you use assembly-internal controls with the Xaml Type Provider you get a runtime error:

System.Windows.Markup.XamlParseException : 'Cannot create unknown type '{clr-namespace:any}MyButton'.' Line number '15' and line position '14'.

Repro:
In the same assembly that contains the type-provided xaml, add a custom control:

namespace any
type MyButton() =
   inherit System.Windows.Controls.Button()

Add a namespace to the xaml and make an instance:

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:any="clr-namespace:any">
    <Grid>
        <any:MyButton x:Name="CustomComponent">This explodes</any:MyButton>
    </Grid>
</Window>
@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Nov 26, 2012

Member

I added a test case, but actually I don't know how to fix this.

Member

forki commented Nov 26, 2012

I added a test case, but actually I don't know how to fix this.

@ovatsus

This comment has been minimized.

Show comment
Hide comment
@ovatsus

ovatsus Nov 26, 2012

Contributor

The workaround for this is to explicitly call Assembly.Load on all assemblies referenced in the XAML. Maybe we can look for the xmlns: declarations in the document and call Assembly.Load on them. This won't solve the problem of using the custom namespace url declared in the assembly infos, but at least should allow to use clr-namespace.

Note: this trick works for me when I use FsWpf (https://github.com/ovatsus/FsWpf/blob/master/FsUiObject.fs) but there I use XamlReader.Load while the FSharpx type provider uses XamlReader.Parse, don't know if that will make a difference.

Contributor

ovatsus commented Nov 26, 2012

The workaround for this is to explicitly call Assembly.Load on all assemblies referenced in the XAML. Maybe we can look for the xmlns: declarations in the document and call Assembly.Load on them. This won't solve the problem of using the custom namespace url declared in the assembly infos, but at least should allow to use clr-namespace.

Note: this trick works for me when I use FsWpf (https://github.com/ovatsus/FsWpf/blob/master/FsUiObject.fs) but there I use XamlReader.Load while the FSharpx type provider uses XamlReader.Parse, don't know if that will make a difference.

@rojepp

This comment has been minimized.

Show comment
Hide comment
@rojepp

rojepp Nov 26, 2012

Contributor

One workaround is to specify the assembly even though it is the same one. The WPF designer doesn't need this though, so it is clearly a hack. :)

        xmlns:any="clr-namespace:any;assembly=FSharpx.TypeProviders.Xaml.Tests"

I am working on this, and Issue #87 at the same time. @ovatsus I am looking at xmlns: declarations in order to support types from 3rd party assemblies. Will check if XamlReader.Load makes it work without the explicit assembly name in xaml. Thanks!

Contributor

rojepp commented Nov 26, 2012

One workaround is to specify the assembly even though it is the same one. The WPF designer doesn't need this though, so it is clearly a hack. :)

        xmlns:any="clr-namespace:any;assembly=FSharpx.TypeProviders.Xaml.Tests"

I am working on this, and Issue #87 at the same time. @ovatsus I am looking at xmlns: declarations in order to support types from 3rd party assemblies. Will check if XamlReader.Load makes it work without the explicit assembly name in xaml. Thanks!

@rojepp

This comment has been minimized.

Show comment
Hide comment
@rojepp

rojepp Nov 26, 2012

Contributor

I've tried progressing in this, but the best I can do is the workaround mentioned above.
This has to do with the target type not really existing at design/compile time because the assembly hasn't been built yet. When we add the assembly name per the workaround, I guess it is really referencing a previous version of itself. Messy..

If no-one has any ideas we should probably close this issue and document it somewhere?

Contributor

rojepp commented Nov 26, 2012

I've tried progressing in this, but the best I can do is the workaround mentioned above.
This has to do with the target type not really existing at design/compile time because the assembly hasn't been built yet. When we add the assembly name per the workaround, I guess it is really referencing a previous version of itself. Messy..

If no-one has any ideas we should probably close this issue and document it somewhere?

@forki forki closed this Nov 27, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment