We ported all package info from our docs site to the add-on market - sorry about the 404, we will get that fixed.
The package will give you the source code for a data type you created via the visual tools and the guidance on the page should desctibe how you can transition from a "dynamic data type" to a "static data type".
You don't have to move your data types to code, but I would recommend it. You are not dependent on the type that Composite C1 auto generate and put in Composite.Generated.dll.
Anyway, my suggestion to put your data type into code was mostly motivated by that you are building a media data provider and you use data types to store meta data out your media. In such a setup, where you have a media data provider (which is a code based plug-in you copy to bin) it makes a lot of sense that you have the data types in code also, so your plug-in will 'bring its own stuff to the table'.
The package will give you the source code for a data type you created via the visual tools and the guidance on the page should desctibe how you can transition from a "dynamic data type" to a "static data type".
You don't have to move your data types to code, but I would recommend it. You are not dependent on the type that Composite C1 auto generate and put in Composite.Generated.dll.
I don´t know if i have to put my plugin files in a DLL or i can reference my plugin directly from inside the c1 project.What exactly are you building? Typically plug-ins are packaged in assemblies (they are DLL files) you drop into ~/bin and (often) register in Composite.config.
Anyway, my suggestion to put your data type into code was mostly motivated by that you are building a media data provider and you use data types to store meta data out your media. In such a setup, where you have a media data provider (which is a code based plug-in you copy to bin) it makes a lot of sense that you have the data types in code also, so your plug-in will 'bring its own stuff to the table'.