Skip to main content

How to deploy and debug remote on a Windows 8 tablet using Visual Studio

Si iata ca am ajuns in momentul in care putem sa testam aplicatii Metro pentru Windows 8 direct de pe tablete. Daca ati dezvoltat aplicatii pentru Windows Phone 7 pana acuma si ati facut deploy si debug pe device, trebuie sa stiti ca acest proces este destul de asemanator.
Cea ce s-a schimbat este modul in care conectati device-ul la calculator. Daca telefonul se conecta prin intermediul unui cablu, iar pe masina era "have to" sa aveti instalat Zune, pentru a face deploy si debug la o aplicatie pe o tableta cu Windows 8, tot ce aveti nevoie pe langa device este ca acesta sa fie conectat la retea. Tableta poate sa fie conectata la retea atat prin WiFi, cat si prin cablu de retea (depinde de ce model aveti).
Pentru a putea face deploy la aplicatie este nevoie ca sa instalati pe tableta Visual Studio 2011. Odata ce ati facut acest lucru in START o sa puteti gasi Remote Debugging Monitor (executabilul se numeste msvsmon.exe). Acesta trebuie pornit pe tableta si lasat sa ruleze. Prin intermediul acestuia o sa puteti face remote deploy si debug. Trebuie sa va spun ca fata de versiunea pentru VS 2008, cu care am lucrat acu 2 ani pe un alt proiect acesta a fost foarte mult imbunatatit, nu am avut nici o problema cu el.
Ca procesul de deploy sa fie cat mai simplu si deoarece in general cand facem deploy si debug suntem intr-o retea sigura va recomand ca dupa ce ati pornit Remote Debugging Monitor sa deschideti Tools->Options si sa selectati optiunea de "No Authentication" si sa aveti grija sa lasati bifata optiunea de "Allow any user to debug". Intr-o retea sigura daca lasati aceste optiuni active o sa va complicati putin viata, mai ales intr-un mediu corporate unde avem un Active Directory si toata povestioara.
De pe masina de development, pentru a putea deploy pe tableta trebuie sa specificati adresa IP a tabletei sau numele care ati dat la tableta in Visual Studio. Pentru a obtine IP-ul la tableta nu incercati sa cautati cmd.exe si sa executati ipconfig.exe, deoarece in acest moment nu aveti parte de cmd.exe. Ce puteti face este sa deschideti conexiunea curenta la retea si sa dati click pe details. Acolo o sa puteti gasi adresa IP.
Odata ce ati deschis Visual Studio 2011 impreuna cu solutia voastra, selectati proiectul de UI si dati click dreapta, iar apoi "Properties". In tabul "Debug", este nevoie sa selectati la "Target Device" valoarea "Remote Machine" - puteti sa folositi atat IP-ul sau numele la tableta. Va recomand sa folosti numele la tableta, deoarece IP-ul in general nu este fix. Debiti optiunea de "Use authentification" deoarece nu aveti nevoie de ea in acest moment.
In cazul in care vreti sa setati ca doar anumiti useri sa poate face deploy, va recomand ca in prima faza sa urmati pasii de mai sus, iar doar apoi sa incepeti sa restrictionati cine poate sa faca deploy si debug.
Va mai recomand sa selectati si optiunea "Always re-install my package", ca sa fiti siguri ca ultimele modificari ajung pe tableta.
Spor la deploy!

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see

Navigating Cloud Strategy after Azure Central US Region Outage

 Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage.   But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provided a too