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(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

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