I was working on a form created in code-first which was working perfectly, despite being modified constantly for the last couple of days. The DLL that contained the code-first form also contained FieldTypes, PreValue Source Types and PreValue Sources.
I decided to relocate the FieldTypes, PreValue Sources and PreValue Source Types to a separate project and keep the code-first form alone in it's own project. After replacing the DLL with the code-first form (plus other stuff) in the bin directory with the new DLL (the one with the code-first form by itself), I get a YSOD in the backend with the following error:
No provider with id '4085adac-0dba-11e4-8c8d-9c301e5d46b0' found
Description: An unhandled exception occurred during the execution of
the current web request. Please review the stack trace for more
information about the error and where it originated in the code.
Exception Details: Umbraco.Forms.Core.Common.ProviderException: No
provider with id '4085adac-0dba-11e4-8c8d-9c301e5d46b0' found
Source Error:
An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of
the exception can be identified using the exception stack trace below.
If I add the DLL to the bin directory of a test site, I can see that the form's GUID has changed. Why did it change if it's essentially the same form? Is there a way I can set the form's GUID to its previous value?
I need to remove the YSOD because its happening in a production site. Is it possible to do so without having to re-install Contour?
Thanks for the quick reply. I’m pretty sure I’m referencing correctly all of the custom fieldtypes, but I can double check in a moment. I’m sorry to ask for this but, how do I set the form's GUID? I can’t seem to find that in the documentation.
I was so hell-bent on finding a "GUID" form attribute that I completely overlooked the "id" attribute. Good to know that.
Anyways, concerning the error, you sort of put me in the right direction. It turns out that someone had changed the GUIDs of the custom fieldtypes. The form's fields were stored in the database (in the UFFields table) with the custom fieldtypes' old GUIDs. All I had to do was delete these rows from the table, restart the site in IIS, and the form's fields were stored again in the database with the new GUIDs. After that, everything seems to be working out just fine (so far).
Code First form GUID changed after compilation
Hi everybody,
I was working on a form created in code-first which was working perfectly, despite being modified constantly for the last couple of days. The DLL that contained the code-first form also contained FieldTypes, PreValue Source Types and PreValue Sources.
I decided to relocate the FieldTypes, PreValue Sources and PreValue Source Types to a separate project and keep the code-first form alone in it's own project. After replacing the DLL with the code-first form (plus other stuff) in the bin directory with the new DLL (the one with the code-first form by itself), I get a YSOD in the backend with the following error:
If I add the DLL to the bin directory of a test site, I can see that the form's GUID has changed. Why did it change if it's essentially the same form? Is there a way I can set the form's GUID to its previous value?
I need to remove the YSOD because its happening in a production site. Is it possible to do so without having to re-install Contour?
Thank you for your help.
Comment author was deleted
You can set a guid on a code first form then it will never change :)
For the error, probably because you are missing a custom fieldtype
Hi Tim!
Thanks for the quick reply. I’m pretty sure I’m referencing correctly all of the custom fieldtypes, but I can double check in a moment. I’m sorry to ask for this but, how do I set the form's GUID? I can’t seem to find that in the documentation.
Comment author was deleted
In the form attribute :)
Tim,
I was so hell-bent on finding a "GUID" form attribute that I completely overlooked the "id" attribute. Good to know that.
Anyways, concerning the error, you sort of put me in the right direction. It turns out that someone had changed the GUIDs of the custom fieldtypes. The form's fields were stored in the database (in the UFFields table) with the custom fieldtypes' old GUIDs. All I had to do was delete these rows from the table, restart the site in IIS, and the form's fields were stored again in the database with the new GUIDs. After that, everything seems to be working out just fine (so far).
is working on a reply...