Retraso de Visual Studio entre varios proyectos de inicio?

Question

cómo agregar un poco de retraso entre los proyectos de inicio en la solución?

Quiero proyecto de cliente que se inició después de 2-3 segundos de iniciarse servicio de windows.

¿Por qué necesito esto?

WindowsService ejecuta el servidor de socket y el cliente ejecuta el socket para conectarse al servidor. WindowsService carga lentamente que Client, y esto causa una excepción en el lado del cliente cuando se conecta al servidor que aún no se ejecuta

Answer 1

Probablemente agregue un mecanismo de reintento dentro del cliente. De esta forma no solo ayuda en el caso de "iniciar desde Visual Studio": también ayuda si el servidor se reinicia mientras el cliente real se conecta. El hecho de que el servidor esté en una máquina más rápida no significa que el servidor nunca tenga que reiniciarse, ¿o sí?

De hecho, es posible que desee agregar este mecanismo de reintento de tal manera que el cliente pueda recuperar incluso si el servidor se reinicia , mientras que está conectado. Depende de lo que el proyecto está haciendo, por supuesto.

Answer 2

Si el cliente necesita iniciarse después, debe ajustar su lista, ya que en este momento comenzado antes!

También codificaría un "/ wait" que al cargar la aplicación si encuentra esa marca, la espera también puede ser útil.

Answer 3

Puede usar el bloqueo Mutex para sincronizar los dos proyectos de inicio.

Programa 1 (proyecto de inicio 1):

namespace ConsoleApplication1 
{ 
    using System; 
    using System.Collections.Generic; 
    using System.Linq; 
    using System.Text; 
    using System.Threading; 

    class Program1 
    { 
     private static bool isNewMutexCreated = true; 
     private static Mutex mutex; 
     static void Main(string[] args) 
     { 
      mutex = new Mutex(true, "Global\\ConsoleApplication1", out isNewMutexCreated); 
      AppDomain.CurrentDomain.ProcessExit += new EventHandler(CurrentDomain_ProcessExit); 
      Console.WriteLine("Application1 executed on " + DateTime.Now.ToString()); 

      Console.ReadKey(); 
     } 

     static void CurrentDomain_ProcessExit(Object sender, EventArgs e) 
     { 
      if (isNewMutexCreated) 
      { 
       Console.WriteLine("Mutex Released"); 
       mutex.ReleaseMutex(); 
      } 
     } 

    } 
} 

Programa 2 (proyecto de inicio 2):

namespace ConsoleApplication2 
{ 
    using System; 
    using System.Collections.Generic; 
    using System.Linq; 
    using System.Text; 
    using System.IO; 
    using System.Threading; 

    class Program2 
    { 
     static void Main(string[] args) 
     { 
      Mutex mutex = null; 
      Thread.Sleep(5000); 

      while (mutex == null) 
      { 
       try 
       { 
        mutex = Mutex.OpenExisting("Global\\ConsoleApplication1"); 

       } 
       catch (Exception) 
       { 
        Console.WriteLine("Mutex not found on " + DateTime.Now.ToString()); 
        Thread.Sleep(3000); 
       } 


      } 
      Console.WriteLine("Application2 executed on " + DateTime.Now.ToString()); 
      Console.ReadKey(); 
     } 
    } 
} 

Answer 4

¿Por qué no acaba de pasar un argumento al cliente aplicación que establece el retraso?

static void main(string[] args) 
{ 
    // Sleep some time 
    int delay; 
    if (args.Length > 0 && int.TryParse(args, out delay)) 
    { 
    Thread.Sleep(delay); 
    } 

    // Initialize client 
} 

Ahora puede agregar el retraso en milisegundos a los argumentos de la línea de comandos para el inicio del proyecto.

También estoy de acuerdo en que, si es posible, es mejor resolver su problema estructuralmente, por lo que no importa cuándo comienzan el cliente y el servidor.

Answer 5

Puede configurar el proyecto de servidor como proyecto de inicio solo y utilizar esta macro para poner en marcha el servidor y el cliente con un retraso:

Sub DebugServerAndClientWithDelay() 
    DTE.Debugger.Go(False) 
    System.Threading.Thread.Sleep(2000) 
    DTE.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate() 
    DTE.ActiveWindow.Object.GetItem("SolutionName\ClientProjectName").Select(vsUISelectionType.vsUISelectionTypeSelect) 
    DTE.ExecuteCommand("ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance") 
End Sub 

Puede añadir un botón a la barra de herramientas o usar una tecla de acceso directo para ejecutar esta macro

Answer 6

En el caso de varios proyectos de puesta en marcha, se cargan en el orden en que se especifican ni de forma simultánea ni aleatoria.http://msdn.microsoft.com/en-us/library/09138bex(v=vs.90).aspx

Entonces, puede ser si especifica "cliente" después de "servicio de ventana", entonces puede entrenar bien. Y si no desea obtener la forma codificada sugerida anteriormente, entonces (para pruebas solamente) puede adjuntar manualmente el proceso "cliente" a su solución desde una solución diferente después de la demora deseada. http://msdn.microsoft.com/en-us/library/c6wf8e4z(v=vs.100).aspx

Answer 7

Simplemente agregue un procedimiento para verificar si la toma está abierta o no. Si el socket está abierto, continúe ejecutando su código e intente verificar nuevamente si el socket no está abierto. De esta forma, incluso si inicia el servicio de Windows más tarde, no habrá ningún problema.

Answer 8

Otra opción más simple para la prueba es simplemente retrasar el cliente si el depurador se adjunta como esto:

if (System.Diagnostics.Debugger.IsAttached) 
{ 
    System.Threading.Thread.Sleep(2000); 
} 

Es posible concluir que en un bloque de #if DEBUG si lo desea. De todos modos creo que esto debería ser la menor cantidad de trabajo :)

Answer 9

Para la aplicación n-tier en la que estoy trabajando actualmente, combiné el método Mutex sugerido por Romil (código ligeramente diferente pero el mismo principio) y lo encapsulé dentro de un método con un atributo [Conditional ("DEBUG")] aplicado (por lo que se quita en el modo de lanzamiento). También rodeamos la lógica mutex con if (System.Diagnostics.Debugger.IsAttached) {...} ya que las versiones QA usan el modo Debug.

Originalmente usamos un Thread.Sleep con un período de espera que funcionaba para la mayoría de las máquinas de desarrollo, pero tuvimos problemas porque la velocidad de la computadora de los desarrolladores varió y como agregamos más y más al servidor de arranque, tuvimos que mantener aumentando el período de espera.