PropertyGrid crash my custom container

Hi Gordon,

It would be impossible to tell without seeing it in action. If you can please put together a small sample project that reproduces your issue and email it over then we can take a closer look. Be sure to remove any executables or change the extension of the zip file to ensure it gets past our email filters.

I send the email with a simple project zip file to mailer@. But how do I attach files from these forum?

Sorry but we don't have attachment support at this time in our forum.  You can mail it to our support address instead.  The mailer address isn't checked.

I also down load the SplitContainer from CodePlex.com and the same thing happended: Here is the scenery:

1) Build and Compile on your own machine which has ActiPro property grid installed, my build machine is Windows 7 with .Net 4 installed. (Runs fine on my own machine)

2) Copy to the executable and dlls on a remote machine (it may not have property grid installed), login to that machine and run it from there. These machine may not have same OS as your build machine. My remote machine that application crashes is the Windows Server 2003 and 2008.

Hi Gordon,

Thank you for the sample, but I wasn't able to reproduce the crash you describe. Are you saying that it only crashes on machines other than your development machine? If so, it may be a licensing issue or you may need to make sure the .NET runtime has any patches applied. We don't switch any logic based on the OS version or .NET runtime version.

It is only happens on the othermachine that does not have property grid control installed.

We have site license for our company for the propertygrid. How did we do to make these issure to go away, especially when diliver the products to the clients. But I still don't think it is the license issue though.

Hi Gordon,

Can you please post the stack trace and exception information? So does it only happen on Windows Service 2008 machines?

If it were a license issue, you would see it even without the SplitContainer and the exception would indicate as much.

As you suggested, I just put the propertygrid on a window and it does crashes too. So it may be related to the license. And the ActiproSoftware.PropertyGrid.Wpf.dll and ActiproSoftware.PropertyGrid.Wpf.xml is in the same directory as the executable.

How do we fix the license issue? We have site license.

But if we deliver our products to the clients, are we going to have same issue or we need to install the propertygrid on the clients machine? Please tell us how to fix the license issue.

The trace message says it may be different propertygrid when compiling or loading, but they are the same.

The following is the trace:

System.Windows.Markup.XamlParseException was unhandled
Message= Cannot find type 'ActiproSoftware.Windows.Controls.PropertyGrid.PropertyGrid'. The assembly used when compiling might be different than that used when loading and the type is missing. Error at object 'System.Windows.Controls.Grid' in markup file 'Window1.xaml' Line 38 Position 10.
Source=PresentationFramework
LineNumber=38
LinePosition=10
StackTrace:
at System.Windows.Markup.XamlParseException.ThrowException(String message, Exception innerException, Int32 lineNumber, Int32 linePosition, Uri baseUri, XamlObjectIds currentXamlObjectIds, XamlObjectIds contextXamlObjectIds, Type objectType)
at System.Windows.Markup.XamlParseException.ThrowException(ParserContext parserContext, Int32 lineNumber, Int32 linePosition, String message, Exception innerException)
at System.Windows.Markup.BamlRecordReader.ReadRecord(BamlRecord bamlRecord)
at System.Windows.Markup.BamlRecordReader.Read(Boolean singleRecord)
at System.Windows.Markup.TreeBuilderBamlTranslator.ParseFragment()
at System.Windows.Markup.TreeBuilder.Parse()
at System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream)
at System.Windows.Application.LoadBamlStreamWithSyncInfo(Stream stream, ParserContext pc)
at System.Windows.Application.DoStartup()
at System.Windows.Application.<.ctor>b__0(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Boolean isSingleParameter)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.TranslateAndDispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Application.RunInternal(Window window)
at SplitContainerDemo.App.Main() in D:\NoBackup\MS SplitContainer\SplitContainerDemo\obj\Debug\App.g.cs:line 0
InnerException: System.ApplicationException
Message=Cannot find type 'ActiproSoftware.Windows.Controls.PropertyGrid.PropertyGrid'. The assembly used when compiling might be different than that used when loading and the type is missing.
Source=PresentationFramework
StackTrace:
at System.Windows.Markup.BamlMapTable.GetTypeFromId(Int16 id)
at System.Windows.Markup.BamlRecordReader.GetElementAndFlags(BamlElementStartRecord bamlElementStartRecord, Object& element, ReaderFlags& flags, Type& delayCreatedType, Int16& delayCreatedTypeId)
at System.Windows.Markup.BamlRecordReader.BaseReadElementStartRecord(BamlElementStartRecord bamlElementRecord)
at System.Windows.Markup.BamlRecordReader.ReadElementStartRecord(BamlElementStartRecord bamlElementRecord)
at System.Windows.Markup.BamlRecordReader.ReadRecord(BamlRecord bamlRecord)
InnerException:

Thank you for the exception detail.  That is not a license exception.  That message is from .NET itself and seems to be saying that the PropertyGrid.dll assembly you referenced when building your .exe isn't the same PropertyGrid.dll assembly that you are deploying.

Are you sure that you are deploying the same PropertyGrid.dll version with your app that you are referencing in your project references?  In Visual Studio, when you have the reference selected in your project, show the Properties tool window and see if Specific Version is set on and Copy Local.  Probably turn both those on and deploy fhe version it put in your bin folder from that.

I did do that, Copy Loca = true, Specific Version = True. Version=11.2.552.0 and Runtime Version=V2.0.50727 Aliases=global and Strong Name=True.

Thanks

Gordon

We're about to close down now since it's 5pm but I'll try and check for a reply later.  So if you have those set, and you rebuild your solution, then using Windows Explorer go to the bin folder, and run the application there, do you see the problem? 

If not, and you take that exact same bin folder and move it to another machine and run it there, do you see it there?

If so, I wonder if there is some issue with the GAC happening here where either on your dev machine or on the deployment machine, a different version is getting pulled in by .NET from the GAC.  Do you have any versions of the PropertyGrid assembly in the GAC on either/both machines?  If so, which?  And if so, maybe try pulling it out of the GAC to see if that helps.

I did just that copy the whole debug folder onto another machine. When I run it on that machine, it crashes. but I run it on my own machine from that same folder, then it is OK. I don't have any other version of PropertyGrid on my machine or on the another machine. What is the GAC here. I have other third party controls but they are working...

Thanks

Gordon

The GAC (global assembly cache) is where assemblies can be stored for any app to pull in by name (their path doesn't need to be known).  I was curious if you had our assemblies in the GAC on your other machine.  If you've never installed our product there though, it shouldn't be in the GAC there.  But sometimes .NET assembly binding will pull GAC assemblies instead of other ones, which is why I asked.  Although if you have specific version set, etc. I would think you'd be ok there.

A couple other things to check...

1) Did you also deploy our Shared assembly, as that is required for PropertyGrid?  Perhaps you didn't include that and this exception message .NET is giving is not reporting that properly?

2) Just in case this exception is wrapping some form of license exception (but in that case it usually says the PropertGrid type can't be created, not anything about an assembly difference), have you followed all the steps in the Licensing documentation topic, and properly included a licenses.licx file in your project? 

3) Make sure your app's exception reporting mechanism also goes down the inner exception chain, if any, of this exception to find the innermost one.  Since maybe that will give us more info.  Try that and see if any more info pops up.

Thanks a lot, we did miss the share.wpf.dll and after that it is not crash anymore.