Visual Studio
Aucun message portant le libellé Visual Studio. Afficher tous les messages
Aucun message portant le libellé Visual Studio. Afficher tous les messages

VSTS: The request requires authentication.

Suite à l'ajout d'un compte externe au projet Visual Studio, l'utilisateur n'était pas capable de se connecter au projet. Le message d'erreur suivant s'affichait:

401 NOT AUTHORIZED
The request requires authentication.


Afin d'avoir accès au projet, il faut s'assurer que l'utilisateur externe accepte l'invitation reçue par courriel.

Dynamics AX : Show Installed Models retourne la mauvaise information

Après avoir fait un refresh de mon environnement de Dev, j'ai réalisé que la version de l'un des modèles installée n'était pas à jour. Pourtant, j'avais bel et bien restauré les deux bases de données (Business & Model). De plus, je pouvais voir que les objets de la plus récente version étaient dans l'AOT. Le problème était uniquement la numérotation du Model.

Le problème résidait dans une vielle version du fichier Model.xml situé dans mon repository folder. Après avoir effacé le fichier, la bonne version est apparue.



Dynamics AX : The working folder is already in use by the workspace

Lorsque vous configurez Dynamics AX afin d'utiliser Version Control avec Team Foundation Server, Visual Studio crée un workspace privé dans TFS. Lorsqu’un utilisateur, autre que le propriétaire du workspace TFS, ouvre le client Dynamics AX, il reçoit le message d’erreur suivant:

The working folder C:\FolderName is already in use by the workspace PCNAME_AXWORKSPACE;username on computer PCNAME


Ce message d’erreur m’a forcé à faire plus de recherche sur la configuration des workspaces.

Tout d’abord, j’ai voulu voir la liste de workspace associer à la machine. Pour ce faire, vous pouvez utiliser l’outil ts workspace en ligne de commande. L’outil se trouve dans le dossier suivant:

C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE

Voici la commande afin de voir tous les workspaces associés à une machine:

tf workspaces /computer:PCNAME /owner:* /collection:http://tfsserver:8080/tfs/CollectionName/


Selon le message d’erreur, je sais que le workspace utilisé par Dynamics AX est DEV-PC3_AXWORKSPACE3. Donc, j’aimerais supprimer tous les autres workspaces. Pour ce faire, je dois supprimer les workspace un par un en utilisant la commande suivante:

tf workspace /delete WORKSPACE;domain\username /collection:http://tfsserver:8080/tfs/CollectionName/


S'il y a beaucoup de workspaces, vous pouvez aussi utiliser Visual Studio pour les supprimer. Au final, il me reste un seul workspace associé à ma machine:


Afin de résoudre mon problème d'accès, je vais changer les permissions du workspace associé à Dynamics AX. 

tf workspace /collection:http://tfsserver:8080/tfs/collectionname/ WORKSPACE;domain\username

Je confirme que mon DEV-PC3_AXWORKSPACE est associé au workspace local qui est configuré dans AX.




Cliquer sur Advanced. C'est ici que vous pouvez modifier les permissions du workspace

Private: Only the owners can use, check in files to, or administer the workspace.

Public Limited: Any valid user can use the workspace. However, only the owners can check in files to or administer the workspace.

Public: Any valid user can use, check in files to, or administer the workspace.


Personnellement, je le configure à public limited. Les autres utilisateurs qui utilisent l'environnement AX peuvent accéder au workspace, mais sans pouvoir faire des check-ins. Donc, je n'ai plus d'erreurs d'accès lorsque les autres utilisateurs ouvrent AX.

Je change le propriétaire du workspace lorsqu'un nouveau développeur prend possession de la machine de développement.

Sources: 

Dynamics AX 2012 : Loading this assembly would produce a different grant set from other instances

Dans un environement Dynamics AX 2012 R3 avec Visual studio 2013 update 4, un développeur recevait le message suivant lorsqu'il tentait de compiler certains rapports. 

Loading this assembly would produce a different grant set from other instances (Exception from HRESULT: 0x80131401)

The "GenerateRdlTask" task failed unexpectedly.


La majorité de mes recherches suggère les même solutions: effacer les fichiers temporaires de Microsoft .NET Framework, effectuer un IISRESET et de modifier le fichier web.config.

Malheureusement, cela n'a pas corrigé le problème.

La bonne nouvelle, c'est que j'ai finalement réussi à faire fonctionner la compilation des rapports sur mon serveur, la mauvaise nouvelle est que je ne suis pas certain comment j'ai réglé le problème. Je vais énumérer ici tout ce que j'ai fait afin de faire fonctionner la compilation.

Premièrement, assurez-vous que ce n'est pas un problème avec le profil de l'utilisateur. Faite un test avec un nouvel utilisateur. Si ça fonctionne, il suffit de recréer le profil de l'utilisateur.
Ensuite, voici les étapes que j'ai faite en ordre chronologique

J'ai ajouté la clé de registre COMPLUS_LoaderOptimization 


Ensuite, j'ai désactivé l'anti-virus sur le serveur

J'ai désinstallé les composants .NET Framework 4.5 sur le serveur
  • Microsoft .NET Framework 4.5 Multi-Targeting Pack
  • Microsoft .NET Framework 4.5 SDK
  • Microsoft .NET Framework 4.5 Multi-Targeting Pack
  • Microsoft .NET Framework 4.5 Multi-Targeting Pack (ENU)
  • Microsoft .NET Framework 4.5 SDK

J'ai aussi désinstallé reporting Services Extensions, Visual studio Tools et le debugger.

Ensuite, j'ai supprimé le dossier DynamicsTools

  • C:\Programme Files\MSBuild\Microsoft\Dynamics Tools

et au final, j'ai ajouté le variable système comme indiquer ici


À partir de ce moment, la compilation fonctionnait pour mon utilisateur, mais ne fonctionnait pas sous le profil développeur. J'ai donc fait une sauvegarde du profil et ensuite je l'ai supprimé. Avec un nouveau profil, il était maintenant capable de compiler les rapports.

Ensuite, j'ai réinstallé Reporting Services, Visual studio Tools et le debugger. 

Voilà.
S'abonner à : Messages (Atom)