Skip to main content

Besoin de vider le dossier obj avant une build ?

Par moment, il est utile de vider le dossier obj avant de lancer une build. S’il faut la faire avant chaque build, ce petit désagrément devient vite insupportable. Il existe heureusement une solution.

Il suffit d’ajouter l’élément suivant à la fin du fichier .csprpoj :


<Target Name="CleanObj" BeforeTargets="BeforeBuild">
    <RemoveDir Directories="$(BaseIntermediateOutputPath)" />
</Target>

Personnellement, je réserve cette opération aux builds en mode Release. Je refaire donc utiliser la version suivante :


<Target Name="CleanObj" BeforeTargets="BeforeBuild" Condition="'$(Configuration)'=='Release'">
    <RemoveDir Directories="$(BaseIntermediateOutputPath)" />
</Target>
Jérémy Jeanson

Ouvrir un fichier Excel avec VSTO sans l’afficher

À défaut, quand on créé un add-in Office avec les Visual Studio Tools for Office (VSTO pour C# et VB), l’ouverture de documents ouvre une nouvelle fenêtre par document. Ceci est valable pour tous les types de documents Office (Word, Excel, Poser Point, Visio…).

Si l’on souhaite cacher la fenêtre de ce document, on peut utiliser la collection Windows de celui-ci. Il y a cependant quelques effets de bord :

  • On ne peut exécuter aucune macro du fichier.
  • Le fichier peut demander à être enregistré à fermeture d’office (mais on peut ajouter un code à l’add-in pour interdire l’enregistrement).

Heureusement, il existe une solution plus élégante sous Excel : utiliser la propriété IsAddin du fichier. Celle-ci bien fait comprendre à office que le document est à considérer comme un add-in (ou un complément à notre add-in).

Comme indiqué par la documentation Excel, ceci a en plus les avantages suivants :

  • Il n’est jamais demandé à l’utilisateur d’enregistrer ce document.
  • Le document n’est pas visible.
  • La liste des macros n’est pas accessible à l’utilisateur (via les listes, et boites de dialogues).
  • On peut exécuter les macros du fichier.
  • La touche Shift n’a pas d’impact si elle est pressée lors de l’ouverture du document (l’utilisateur ne peut donc pas utiliser le debuger de macros Office pour intercepter vos macros)

Exemple d’utilisation :


// Fermeture du classeur courant
Globals.ThisAddIn.Application.ActiveWorkbook.Close(SaveChanges: false);

Workbook wb = Globals.ThisAddIn.Application.Workbooks.Open(
    // Fichier
    Filename: "MonFichier.xls",
    // Edition interdite
    ReadOnly: true,
    // Ne pas ajouter à l'historique
    AddToMru: false
    );

// Activer les macros
_wb.RunAutoMacros(Microsoft.Office.Interop.Excel.XlRunAutoMacro.xlAutoActivate);

//_pgpp.Application.Visible = false;
_wb.IsAddin = true;
Jérémy Jeanson

Le singleton le plus court au monde s’écrit en C#

Depuis des années, j’écris des singletons avec le code suivant :


private static readonly MyClass Instance;

/// <summary>
/// Constructeur static
/// </summary>
static MyClass()
{
    // Instantiation du singelton
    Instance = new MyClass();
}

/// <summary>
/// Instance courante unique
/// </summary>
public static MyClass Current { get { return Instance; } }

/// <summary>
/// Constructeur privé
/// </summary>
private MyClass()
{
}

Mon singleton n’étant jamais supprimé, il n’est donc pas besoin d’être vérifié et instancié lors du Get. Je n’utilise pas de lock pour l’instanciation, car mon instance est créée via le constructeur statique (celui-ci ne peut être appelé qu’une fois).

Avec les dernières optimisations et simplifications de C# (propriétés privées en lecture seule), mon Singleton est devenu toujours plus court (2 lignes spécifiques):


/// <summary>
/// Constructeur statique
/// </summary>
static MyClass()
{
    // Instantiation du singelton
    Current = new MyClass();
}

/// <summary>
/// Instance courante unique
/// </summary>
public static MyClass Current { get; }


/// <summary>
/// Constructeur privé
/// </summary>
private MyClass()
{
}

À quand le Singleton en une ligne ?

Jérémy Jeanson

ALINK et x64 : L'assembly référencé 'mscorlib.dll' cible un processeur différent

Peut-être avez-vous déjà rencontré le warning suivant :

L'assembly référencé 'mscorlib.dll' cible un processeur différent


Celui-ci se produit sur des projets exploitant des fichiers .resx quand on veut les compiler en 64 bits.

Un très vieux problème à l’époque de Visual Studio 2010 provoquait le même warning. En furetant ici et là sur le web on peut trouver diverses solutions plus ou moins compliquées pour résoudre ou contourner ce warning. Mais l’ensemble de ces solutions mixées ou mises bout à bout ne fonctionne pas sur Visual Studio 2017 (ou alors elles incluent des manipulations inutiles).

Pour résoudre le problème, il faut que le projet concerné indique à Visual Studio où se trouve le SDK en version 64 bits (c’est là que se trouve l’utilitaire dont Visual Studio 2017 a besoin lors de la compilation). Il se trouve que la seule différence entre la version 32, et la version 64 est qu’il faut ajouter x64 au nom du dossier en version 64 bits.

L’information doit être ajoutée en toute fin du fichier .csporoj (juste avant la balise fermante </Project> ).


<Target Name="Resx" BeforeTargets="BeforeBuild" >
  <PropertyGroup Condition="'$(Platform)'=='x64'">
    <TargetFrameworkSDKToolsDirectory>$(TargetFrameworkSDKToolsDirectory)$(Platform)\</TargetFrameworkSDKToolsDirectory>
  </PropertyGroup>
</Target>

Description de la modification :

  • Target a une propriété Name donnée en rapport avec le problème à résoudre. Mais on peut très bien lui donner un autre nom (du moment qu’il n’est pas déjà utilisé ou qu’il ne s’agit pas de BeforeBuild ou AfterBuild)
  • Target a un attribut BeforeTargets égale à BeforeBuild, car l’information doit être disponible avant la build.
  • PropertyGroup a une Condition pour n’utiliser les porpiétés qui suivant qu’avec la compilation en 64 bits.
  • TargetFrameworkSDKToolsDirectory est le chemin que l’on veut définir.


Je n’ai pas fourni de liens vers des solutions similaires, car comme évoqué plus haut, elles ne concernent pas de cas, ou incluent plus de modifications que nécessaire.

Jérémy Jeanson

Cookies Cookie Policy

This website uses cookies and similar technologies to allow us to promote our services and enhance your browsing experience. If you continue to use this website you agree to our use of cookies.