Voici donc un message d'erreur obtenu lors de l'exécution d'une requête Lync sur une de mes tables gérées à travers DataAccess ORM de Telerik (anciennement OpenAccess).
A en croire ce message je n'ai pas de clef définie sur cette table. Et pourtant... dans le model, j'ai bien une clef de défini. Pour remédier à ce soucis, j'ai dû supprimer la clef, puis enregistrer mes modifications, j'ai eu droits à quelques messages d'erreur correspondant aux FOREIGN KEY qui ne pouvait plus se résoudre. J'ai remis en place ma clef, resauvegarder, puis exécuter l'application et... problème résolu.
Pour supprimer/créer la clef j'ai juste passé de false à true le propriété Identity de mon champ clef.
vendredi 12 décembre 2014
ClickOnce
Pas grande chose à voir avec DotNetNuke (sujet principal de ce blog). Mais voici une problématique face à laquelle je me suis retrouvé et qui m'a donné quelques sueurs froides : le renouvellement d'un certificat d'une application ClickOnce.
Lors de la création d'une application ClickOnce, les manifestes sont automatiquement signés. En effet, la case à cocher "Signer les manifestes ClickOnce" se trouvant dans l'onglet "Signature" des propriétés du projet est pré-coché. Cela ne pose aucune problème jusqu'à la date de péremption du certificat c'est à dire 1 an après la première publication.
Après que se passe-t-il ? Plusieurs possibilités :
Pour info le certificat généré initialement, se trouve normalement à la racine de votre projet.
Voici l'article que vous permettra de procéder au renouvellement du certificat : http://robindotnet.wordpress.com/2010/01/26/how-to-extend-an-existing-certificate-even-if-it-has-expired/
Pour résumé, il vous faut dans un premier temps récupérer un exécutable permettant de renouveler le certificat, celui-ci a pour nom "renewcert.exe".
Ensuite, exécuter la ligne de commande suivante :
Vous obtiendrez alors un fichier certificat pfx dont la date aura été étendue de 5 ans. Il ne vous reste plus qu' remplacer votre ancien certificat en passant par les propriétés du projet onglet "Signature" puis le bouton"A partir d'un fichier...".
Problème réglé.
Lors de la création d'une application ClickOnce, les manifestes sont automatiquement signés. En effet, la case à cocher "Signer les manifestes ClickOnce" se trouvant dans l'onglet "Signature" des propriétés du projet est pré-coché. Cela ne pose aucune problème jusqu'à la date de péremption du certificat c'est à dire 1 an après la première publication.
Après que se passe-t-il ? Plusieurs possibilités :
- vous créez un nouveau certificat, cela induit que vous acceptiez que vos utilisateurs doivent supprimer votre ancienne version pour installer la nouvelle... pas vraiment pratique,
- vous avez sous le coude le certificat (fichier .pfx) qui a été créé initialement, et là vous n'avez plus qu'à le prolonger et redéployer et c'est reparti pour un tour,
- vous n'avez pas le certificat, et là vous pouvez soit pleurer, soit accepter "contraint et forcer" la première solution.
Pour info le certificat généré initialement, se trouve normalement à la racine de votre projet.
Voici l'article que vous permettra de procéder au renouvellement du certificat : http://robindotnet.wordpress.com/2010/01/26/how-to-extend-an-existing-certificate-even-if-it-has-expired/
Pour résumé, il vous faut dans un premier temps récupérer un exécutable permettant de renouveler le certificat, celui-ci a pour nom "renewcert.exe".
Ensuite, exécuter la ligne de commande suivante :
renewcert <FichierPfxOrigine> <FichierPfxDestination>.
Vous obtiendrez alors un fichier certificat pfx dont la date aura été étendue de 5 ans. Il ne vous reste plus qu' remplacer votre ancien certificat en passant par les propriétés du projet onglet "Signature" puis le bouton"A partir d'un fichier...".
Problème réglé.
dimanche 12 octobre 2014
DNN + Bootstrap + DDRMenu : Comment garder ouvert un sous-menu
Voici une petite astuce à utiliser dans un cas très précis. Je travaille actuellement sur un skin DNN, basé sur Bootstrap. Arrive le moment tant redouté de l'intégration du menu DNN (DDRMenu) dans le skin et je rencontre là un problème pour la gestion du menu "Rechercher".
En effet, dans DNN lors de la sélection du menu rechercher, un panel s'ouvre permettant de saisir le texte rechercher. Pour intégrer ce genre de fonctionnalité avec Bootstrap, l'utilisation d'un menu dropdown s'impose. Malheureusement lors de la sélection d'un sous-item la dropdown est automatiquement fermé. Mais dans mon cas cela pose soucis, puisque dès que ma zone de texte de mon contrôle de recherche prend le focus, la dropdown se referme.
A tout problème une solution... Voici tout d'abord la définition de mon menu rechercher "à la Bootstrap" :
Pour éviter cela, il s'agit dans un premier temps de supprimer l'attribut "data-toggle='dropdown'" définie sur l'élément "A" de la dropdown. En supprimant cet attribut, la dropdown ne s'ouvre plus.
L'étape suivante consiste à remettre en place le fonctionnement de la dropdown avec du javascript tout en excluant les cas où l'on ne souhaite pas que la dropdown se ferme. Voici le code JS à mettre en place pour arriver à cela :
La seconde partie du script permet de refermer la dropdown (en supprimant la classe "open") sauf dans le cas où l'on clique dans la dropdown.
Avec cela mon problème de menu "Rechercher" est réglé...
En effet, dans DNN lors de la sélection du menu rechercher, un panel s'ouvre permettant de saisir le texte rechercher. Pour intégrer ce genre de fonctionnalité avec Bootstrap, l'utilisation d'un menu dropdown s'impose. Malheureusement lors de la sélection d'un sous-item la dropdown est automatiquement fermé. Mais dans mon cas cela pose soucis, puisque dès que ma zone de texte de mon contrôle de recherche prend le focus, la dropdown se referme.
A tout problème une solution... Voici tout d'abord la définition de mon menu rechercher "à la Bootstrap" :
<ul class="nav navbar-nav searchMenu">Cette définition permet d'avoir une dropdown "Search" qui a pour contenu, lorsqu'on la déplie, le contrôle de recherche DNN constitué d'une zone de texte et d'un bouton "Rechercher". Si l'utilisateur clique dans la zone de texte, la dropdown est automatiquement fermé.
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">Search<b class="caret"></b></a>
<ul class="dropdown-menu">
<li>
<div class="searchBox">
<dnn:Search id="dnnSearch1" runat="server" showsite="false" showweb="false" cssclass="btn btn-success btn-xs" />
</div>
</li>
</ul>
</li>
</ul>
Pour éviter cela, il s'agit dans un premier temps de supprimer l'attribut "data-toggle='dropdown'" définie sur l'élément "A" de la dropdown. En supprimant cet attribut, la dropdown ne s'ouvre plus.
L'étape suivante consiste à remettre en place le fonctionnement de la dropdown avec du javascript tout en excluant les cas où l'on ne souhaite pas que la dropdown se ferme. Voici le code JS à mettre en place pour arriver à cela :
$(document).ready(function () {La première partie du script permet de mettre en place la classe "open" sur le menu dropdown permettant d'ouvrir la dropdown, et cela est fait lors du click sur la dropdown.
$('.searchMenu li.dropdown a').click(function (event) {
$(this).parent().toggleClass("open");
});
$('body').click(function (e) {
if (!$('.searchMenu li.dropdown').is(e.target) &&
$('.searchMenu li.dropdown').has(e.target).length === 0 &&
$('.open').has(e.target).length === 0) {
$('.searchMenu li.dropdown').removeClass('open');
}
});
});
La seconde partie du script permet de refermer la dropdown (en supprimant la classe "open") sauf dans le cas où l'on clique dans la dropdown.
Avec cela mon problème de menu "Rechercher" est réglé...
jeudi 27 mars 2014
Récupération d'une base de données et rattachement à un utilisateur
Voici un problème que je rencontre systématiquement dès lors que je récupère un backup de base de données pour l'intégrer sur un de mes serveurs. Une fois le backup restaurer sur mon serveur, je souhaite définir un utilisateur pour m'y connecter. Généralement je recrée un user existant déjà dans la base que je viens de restaurer et là je me heurte à une erreur SQL 15023 m'informant que le user existe déjà et que je ne peux donc pas le recréer.
Pour résoudre ce problème je me reporte à ce blog où la solution décrite est simple et efficace :
http://blog.sqlauthority.com/2007/02/15/sql-server-fix-error-15023-user-already-exists-in-current-database/
Pour résoudre ce problème je me reporte à ce blog où la solution décrite est simple et efficace :
http://blog.sqlauthority.com/2007/02/15/sql-server-fix-error-15023-user-already-exists-in-current-database/
jeudi 6 mars 2014
Windows Authentication et IIS
Voici un problème qui m'aura bien fait souffrir : je souhaitais mettre en place pour un site sous DNN, un SSO basé sur l'authentification windows. Il s'agissait donc de définir une page ASPX sur laquelle la connexion anonyme était désactivée et l'authentification Windows activée. Sur le papier, cela me permet lorsque je me connecte sur cette page de récupérer automatiquement le compte Windows de l'utilisateur et ainsi de l'identifier automatiquement (SSO donc) pour peu qu'il utilise IE. Pour FireFox et Chrome, quelques manipulations de paramétrage sont a effectuer au préalable pour arriver à ce résultat.
Sur mon poste (un Windows 7 x64), je me suis retrouvé face à un problème terriblement déroutant (cela m'a occupé 1 jour 1/2 avant de trouver la solution). Lorsque je me connectais sur cette page où l'authentification windows était activée, mon navigateur me demandait de m'identifier, chose que je faisais une première fois, puis la fenêtre de login revenait et impossible de s'en défaire... Ma saisie semblait systématiquement incorrecte.
J'ai déployé ma solution sur le poste de mon collègue et avec le même paramétrage je ne rencontrais aucun soucis, j'étais automatiquement identifié sans avoir à saisir la moindre information dans une fenêtre de login. Il y avait bien entendu une différence quelque part... suffisait de la trouver.
Le problème venait du fait que sur mon site web j'avais défini un nom d'hôte, et sur le poste de mon collègue on travaillait en localhost avec un port. En supprimant le nom d'hôte et en travaillant en localhost mon problème était résolu... mais cette solution ne me satisfaisait pas, je tenais à travailler avec un nom d'hôte et pas un port différent.
En creusant pas mal je suis tombé sur cette KB : http://support.microsoft.com/kb/896861. J'ai utilisé la méthode 2 et là plus de soucis : j'ai gardé mon nom d'hôte et j'ai mon SSO qui fonctionne.
Sur mon poste (un Windows 7 x64), je me suis retrouvé face à un problème terriblement déroutant (cela m'a occupé 1 jour 1/2 avant de trouver la solution). Lorsque je me connectais sur cette page où l'authentification windows était activée, mon navigateur me demandait de m'identifier, chose que je faisais une première fois, puis la fenêtre de login revenait et impossible de s'en défaire... Ma saisie semblait systématiquement incorrecte.
J'ai déployé ma solution sur le poste de mon collègue et avec le même paramétrage je ne rencontrais aucun soucis, j'étais automatiquement identifié sans avoir à saisir la moindre information dans une fenêtre de login. Il y avait bien entendu une différence quelque part... suffisait de la trouver.
Le problème venait du fait que sur mon site web j'avais défini un nom d'hôte, et sur le poste de mon collègue on travaillait en localhost avec un port. En supprimant le nom d'hôte et en travaillant en localhost mon problème était résolu... mais cette solution ne me satisfaisait pas, je tenais à travailler avec un nom d'hôte et pas un port différent.
En creusant pas mal je suis tombé sur cette KB : http://support.microsoft.com/kb/896861. J'ai utilisé la méthode 2 et là plus de soucis : j'ai gardé mon nom d'hôte et j'ai mon SSO qui fonctionne.
Inscription à :
Articles (Atom)