Another blog post about struggle with weird compilation errors of universal app solution.

MdilXapCompile code 1004 - error windows cropped

This one occurs only when you’re compiling in Release configuration, otherwise it’s not bothering you. I couldn’t find any solution online (at that time) and we were helpless for about a week. Finally we overcame this issue, when my boss stumbled upon, totally by coincidence, on one of his subscribed feeds (or forums or something else) on a thread with similar description and gave me the solution.

What I had to do, was to remove all the resources files from the packages (nuget packages) folder in the solution. I searched them by the resources phrase and literally selected all the files that were ending with resources and deleted them

Resource files in packages folder - important part cropped

After deleting all the resources (I advice no to use shfit + del, but just del, so that in case of deleting something important you can recover it from the bin) problem was gone, and I was able to compile in Release mode again.


Some links, that might be useful on this matter, after quick googling:

Deploying to Windows Phone fails when using Release build

RateMyApp 1.2.4 alpha prevents Windows Phone Universal App from being deployed to device when compiled in Release

Recently I was struggling with trying to set images (being a byte[] and/or being an Asset file and/or being an IsolatedStorage file) as an Image.Source. I didn’t know what should be the URI in case of dealing with Assets and IsolatedStorage, and I wasn’t sure what to do with a byte array aka byte[] as well. After a bit of research and some advices from my work colleagues I’ve manage to get it to work

If you are curious what Microsoft have to say about it, just go here and check official Image control site, scroll down to Remarks to learn how to set up a images from web URL and from relative URI (e.g. your app Assets). You can also learn from it, that Images are being cached. Every another time, same image, is referenced, it’s being taken from cache. It’s worth having a glimpse, at least on the remarks and examples. But going back to the subject


Image.Source as byte array aka byte[] (using async and await)

I assume, in this example, that you already have a byte array of image data prepared to be displayed on the screen. If not, this is how you can turn your StorageFile into byte array. Now, you can’t just simply assign Image.Source to array of bytes, XAML will not know what to do with it, and how to display transform it to a bitmap an show it on the screen. It will fail. Hopefully, there’s such thing as Converters, which come with help. As for an example, XAML and ViewModel are pretty straight forward and could look like this

The real ‘magic’ happens in the Converter, which looks like this

Few things to notice in this code. First is that we’re using WritableBitmap, which allows us to assign Source with it (empty) and return it from Converter, which releases UI thread, and transform our byte array, inside a separate task, into stream, which then is being set as source of earlier mentioned WritableBitmap. In more deatils, loading of the image is handled in the Task.Run() context, notice lack of await key word in front of the Task.Run() call, which means it will be done in another thread but, app won’t wait until it’s done, hence UI thread won’t be bothered, and app will respond properly on users actions. Another thing to bear in mind here is the dispatcher. Remember, that if you want to make any changes on the screen, in the UI, you need to do them on the UI thread. Dispatcher is the key to do just that. Call RunAsync() method on it, and you’re safe from getting and exception

The application called an interface that was marshalled for a different thread

Last but not least, is that after setting the source SetSource(ms) you need to call Invalidate() method, which will force a redraw of entire bitmap. Oh, and remember that SetSource(ms) method has to be called before you close and/or dispose your InMemoryRandomAccessStream (in this case ms), that’s why it’s being called inside of the using statement.


Image.Source as project file (Assets file)

This one seems to be the easiest one, but it made me sweat a bit when I tried setting relative UriSource of a BitmapImage and assign it as a Image.Source from the code behind. Even though, it’s well documented on the official, msdn, site that I already pointed out in my short prologue (for convenience), and its mechanism is pretty straightforward, it gave me a little headache. Anyway..All you need to do, in your XAML file, is to set a relative path to your project file (usually taken from Assets) like so

and image appears on the screen! Easy! It’s not that simple, though, when you try setting your project file as Image.Source from the code behind. At least not for me, and those who decided not to read the documentation and thought it’s too easy to waste their time. Wrong! It was a mistake, I should have read it, at least just have a look. To spare you the trouble…What I did, thinking that when I set same URI as I did in XAML, which is “Assets/image.png” as a UriSource of a BitmapImage I would get same results. Nope..because what happens in XAML, according to documentation, is that specified URI as the Source of the Image control is being processed in a specific manner

..the string as a URI, and calls the equivalent of the BitmapImage(Uri) constructor

Following this information I wrote:

Wrong again! What actually happens, and you can read about it, some paragraphs below, in the same document (third time’s the charm), that what actually happens, under the hood, with Image.Source URI is that it’s being treated as a relative path suffix, and in the end it looks something like this (depends on the page file – XAML – location in the project)


That lead me to use this code instead, which finally worked

If you want to refer something from you AppData folder you will have to use ms-appdata:/// scheme prefix instead of ms-appx://. You can find more information about it here


Image.Source as IsolatedStorageFile

In this case you don’t have to do much. Just set the image URI as Image.Source and you’re done

The ‘hard’ part is to save and, later on, get the actual ImageUri. In my case, I’m using MvvmCross libraries, which, by the way, I strongly recommend as a general Mvvm framework for Windows RT (Universal apps) and cross platform development, it was pretty easy. After saving it on the device, I had to call NativePath(path) method, which is a part of IMvxFileStore and my URI was ready to use. I’m not getting into more specific on this matter, because it’s not the topic of this post, but you can check MvvmCross File Plugin out, and whole framework, by yourself, just use NuGet and start exploring.

An example of how native URI could look like:


Almost all of the Windows Phone apps have got a small offset on left and right side. I believe that, it’s got something to do with better user experience. As a layman in this matter, I can  just guess that it makes human eye more comfortable to look at content which doesn’t touch edges. Whatever it is, that’s how apps are being developed and we have to accept that. Although, this is not the topic of this blog post, I’m intentionally mentioning about it, because it has influence on how the scrollbars are placed and how do they look like in the app. Yes, scrollbars.


When the content of the page, designed with those both sides offsets, has got a list, grid or a scrollable content in it, the scrollbar itself is placed on the edge of this content, which means, that it resides not exactly on the edge of the screen, as shown on the above screenshot.

Code for the page, that I took above screenshot, is pretty straightforward

As you can see there’s a main container (Grid) with Margin attribute as a defined resource BasePageOffset

In this case, our interests should be focused on the first and third value of this defined resource, which indicates left and right margin, so called offset. Those two make all the content, being placed inside the Grid, to move a bit into the center of the screen. Which makes our ListView and its scrollbar being moved 10 points from the left and right edge of the screen towards the center. Effect of it is visible on the first screenshot. Solution to this issue, is really simple and comes with manipulation of margins.

Notice the negative left margin in the ListView. All right, but after this change the items of ListView are still touching the edge of the screen and whole idea was not to let them to…No problem, you just have to move your ListView ItemsPanelTemplate template the same amount of space (margin) to the opposite direction by, again, setting a margin, like so

After those changes your scrollbar should be on the right place


My example was showed on the ListView control, but this ‘trick’ could be applied to GridView and ScrollerViewer as well


I annoys me the same way it annoys you, but I don’t think there’s any way to get rid of it, permanently. There is a quick cure though, because it happens only when you open a project in Visual Studio that has its configuration set to x64 or ARM, so you can easily undo it with setting it to something that Blend does not windge about.


In my case I end up with this frustrating information presented to my face, when I try to deploy my app to the device (phone). I set up my build configuration to ARM, I finish my day of work, close everything, restart my machine, go home, and the next day I show up in the office, I open up VS and then Blend and then start..Boom!

Design view is unavailable for x64 and ARM target platforms.

How to get rid of it ? Close both, Blend and Visual Studio, but before you close Visual Studio, go to the configuration manager of the project and change its settings to e.g. Any CPU or just something that is not x64 or ARM


Now, re-open your project in Visual Studio and after VS is up and running re-open your project in Blend. Now your nightmare should be gone, and you should be able to design some cool stuff for your app in Blend for Visual Studio.

The other day I got prompted or just checked that update for my Windows Phone 8.1 is available. I wasn’t thinking much and just clicked Update. Everything when smoothly, no problems with installation whatsoever.


The only problem after this update was that for some, unknown for me, reason MMS messages (images and other rich data) stopped working and by that I mean that I couldn’t receive images nor send them. I was constantly prompted, when someone tried to send me some pictures, with information

Get media content now

Which after tapping didn’t do anything besides showing spinning wheel – or whatever progress indicator it shows – for a while and after ‘it’ figured that it cannot download this content from the server it went back to the same state as it was before, which is inglorious Get media content now.


Two things to notice on this image. First, that this message that you cannot open is being kept for you somewhere on the server (probably servers of your plan provider e.g. Vodafone) and those servers are actually trying to resend it to you after a while (highlighted dates) if you did not downloaded it properly, hence you might get a message from your buddy at really random time and date and he or she wouldn’t have anything to do with sending it to you. When you have no knowledge about this behavior, it could be really confusing..I don’t know how long they keep those messages on the servers but my random guess would be ~2 – 4 weeks, so if you are worried of losing something important, don’t, you can easily fix that before this time passes and get your data message.

Second thing about the image, even if it’s completely not your fault and you had nothing to do with this problem of yours, some people are just haters, like one of my friends, and will just insult your phone, provider and probably you as well because of those problems ;]

Anyway..after some research and trying everything that I could try, with every possible combination, starting from old IT trick which is turning off and on the device, through turning off and on my Mobile Data, checking if Wi-Fi connection has something to do with it and again turning it off and on, then turning on and off Flight Mode and finishing on following some weird steps that should help in this case. Nothing helped, I was still unable to send message and receive MMSs. I was testing it by trying to send a image to myself


No luck..I started to check settings and what are my options to make it work. I went to mobile+SIM system settings and started playing with Highest connection speed, changing it from 3G to 4G and back from 4G to 3G. No luck either..


Then I checked SIM settings in the mobile+SIM window, but I didn’t find anything that could help with my problem


I checked messaging options in the Settings –> applications, but there was nothing there that could potentially fix the issue. The situation was hopeless..after quick chat with one of my friends, who had the same problems, he advised me to go to my provider (Vodafone) and ask them for assistance. So I did. The girl that was helping me with it wasn’t perfectly sure what she should look for, and you could feel that she wasn’t particularly familiar with Windows Phone in general. After couple of ‘half blinded’ tries and with a little bit of luck, she finally fixed it.

All you need to do is to re-activate your access point. Unfortunately it’s not that easy as it sounds. Lets open Settings –> access point. You will probably see that there’s already an access point which is configured and active.


If you want to check – view – it’s configuration, just tap it and hold it until you will be prompted with context menu. As you can see there’s no option like re-activate or re-start or whatever would force it to refresh.


You can go and check if all the fields are populated properly, though, but if your MMS messages were working before, the update or whatever happened, then nothing has changed and it’s all good. If for some reasons you feel like it’s not right, you want to double check or you’re just curios, compare it with your provider specification, values should match

Australian Vodafone access point configuration can be found on the official site, besides that you can find more detailed information how to set up your device with this Set up your phone page – just select your phone manufactured and phone model.

Whatever result you will get from this comparison, if some of the fields are not correct or they all are, you have to create a new access point by clicking ‘+’


If your rich messages where working fine before (and you checked that all the values in your current access point are correct), you can just create a fake access point and make it active which will turn your current one to be inactive.


afterwards just activate your old access point and it should force it to refresh, and in result it should let you receive and send pictures. If this procedure helped, you can delete the fake access point and enjoy your rich data messages.

If for some reasons it’s still not working for you, instead of creating a fake access point you could create a real deal one, with all the proper values (taken from e.g. official web site of your provider) and activate it, and check if with this configuration you are able to send and receive rich data messages. When this fails, unfortunately you will have to go, as me, to your provider shop / help point and ask for assistance.