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

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP