Ok, ce n'est pas une bonne pratique du tout, mais il se peut que vous ayez à utiliser dans l'urgence des pages ASPX classiques, ie. provenant d'un site ASP.NET 2.0, sur votre site SharePoint.

Soit vous avez une page qui contient tout (les contrôles + le code associé), soit votre "code behind" est hébergé dans une dll. Dans ce cas, il faut signer la dll, la mettre dans le gac et ajouter cette assembly dans les SafeControls du web.config.

Ensuite, vous allez mettre votre page ASPX dans une blibliothèque de page SharePoint. Lorsque vous exécutez votre page, vous allez recevoir une erreur, qui ressemble à cela (si votre code est dans la page ASPX)

ou à cela (si votre code behind est dans une dll)

Cela signifie que votre ferme SharePoint n'a pas les droits pour exécuter le code d'une page non SharePoint. Il va falloir modifier le web.config, et ajouter sous le nœud

l'élément suivant

<PageParserPath VirtualPath="/path" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />

L'attribut VirtualPath va permettre de restreindre l'ouverture des droits d'exécution du code à un dossier spécifique. Vous pouvez utiliser "*" pour spécifier tous les fichiers d'un chemin spécifique. Vous pouvez également inclure les sous dossiers.

Je répète que cela n'est pas une solution conseillée, préférez les User Controls ou les Web Parts si le temps le permet.

[edit]
Mille excuses auprès de Romain Laffitte avec qui j'ai travaillé sur l'intégration de page ASPX dans SharePoint, et que je n'ai même pas cité ...

Un rappel important, donner des droits d'exécution pour le code inline n'est pas recommandé pour des raisons de sécurité, il faut donc rester prudent lors de l'application d'une telle solution.