Recently NuGet introduced a new way of handling packages within a project. Instead of stuffing references in a separate packages.config file, it introduced storing package references right in the project file instead.
There are several benefits (really, read the hyperlinked document) to that, the biggest one from my perspective is that it doesn't pollute NuGet packages list anymore. Previously, if you installed a package that referenced many transitive packages, then the package manager would show all of them at the same level. The worse case was when you referenced a .NET Standard package to a Xamarin application - in that case you could end up with like 20+ additional packages.
Example: adding (my favorite IoC container) Autofac to a Xamarin Android project would yield all these guys:
Not funny, eh?
So, the PackageReference way will still reference all those but it won't pollute your NuGet packages list anymore. Plus it clearly shows the top level packages under references, like this:
How does one turn on PackageReference mode?
For new projects
I suggest you set PackageReference as default mode using Tools/Options.../NuGet Package Manager window. Note that default is still package.config.
For existing projects
you should migrate packages.config file as described here
. You need Visual Studio 2017 Preview 3 or newer.
That's it - no more polluted lists and many other benefits!
Partially for learning, partially because it might come handy, I decided to build my own Rasbperry PI cluster that would run HypriotOS and Kubernetes. If you search the web you'll see others doing it and I used them as a knowledge source. Some are outdated and perhaps sharing my experience might help somebody. Anyway, here is my story starting with
- 4x Raspberry PI 3
- 4x 32GB microSD - the faster the better
- 4x network cables
- 4x USB cables
- Anker 5 port USB charger
- Mikrotik hEX router
- partially self-designed, self 3d printed stack (open source)
I've decided to go with 4 Raspberries because I have got hEX router which has 5 ports and 4 of them seem enough for experimenting anyway. Make also sure to get short USB and network cables. The later should be flat to consume less space. Those are sadly hard to get in Slovenia, perhaps your best bet is an online shop somewhere (in the EU). Anker is a good USB charger that shouldn't have problems feeding the hardware but any powerful enough would do. Also if you manage to find an USB powered router, you don't need second 220V outlet for the router (currently I need two of these - one for the router and the other for the USB power charger) and have instead a short USB cable just like Raspberries do.
The biggest challenges
Getting short and flat network cables wasn't easy. Online shops outside of Slovenia will help.
Manufacturing and designing the stack that keeps everything together. I've based it on an existing one, but enhanced Raspberry holder
and created a compatible holder for both Anker USB charger
and mikrotik hEX
. I missed one thing though - replacing microSD cards is not easy - I've ended up using tweezers. If I ever update the design, I'll definitely make it easier. But overall it is a solid stack and should do the job just fine.
Connecting the beast
Not much here, router and USB charger need to be powered trough an outlet, all Raspberries need both network cable connected to router and USB one to the USB charger and that's it. Lights will blink and that's it.
Next post will deal with HypriotOS nad Kubernetes installation.
in parameter modifier was introduced in C# 7.2. It lets you pass (value) types by reference but at the same time protect you against modifying the actual instance.
Here is what What's new in C# 7.2 says about it:
in modifier on parameters, to specify that an argument is passed by reference but not modified by the called method.
Basically compiler protects you against modification of the instance in two ways:
- when you try to change a field directly compiler will throw an error
- when you call an instance method, compiler will create a defensive copy of the instance and run that method on the copy
But what happens when calling instance properties? Will compiler create a defensive copy as well? Even for autoimplemented getters? That's the question I've got on my presentation and I wasn't sure about it. On one hand properties in general can implement modification code and in that sense they aren't safe just like methods aren't. On the other hand autoimplemented getters don't implement any modification code.
If I had to guess I'd say there is no need for defensive copies when dealing with autoimplemented getters, while in other cases compiler will resort to defensive copies.
After few experiments and using Reflector to inspect the generated code it turns out that compiler will use defensive copies with properties always, even with autoimplemented getters. You can also check it out with SharpLab.io, which is a great way into digging into (experimental) C#.
Looks like there is some room for improvement.
I created a new Android and iOS/NETStandard Xamarin.Forms application with Visual Studio 2017 15.5.4 and immediately got an exclamation mark on Dependencies node in Common project. Trying to build the solution I got like three errors for start. They were saying something along
Since I had no idea what that message wanted to tell me I went checking for references and I quickly saw that nor Android nor iOS had any NuGet reference present albeit the packages were listed as installed. So, no packages for some reason. I quickly dismissed the possibility of bad "new Xamarin.Forms project" template - Internet would be screaming in such case.
error : Assets file '[APPPATH]\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
After tinkering a bit, I saw that Package Manager window was saying that it can't find a reference to NuGet Source for one of my sources. Which was correct, but I wasn't using that source at all.
It turns out that once disabling that (faulty) source, NuGet was able to restore the packages and project was building.
Actually it was a combination of two problems combined - one was that missing source that prevented NuGet to download packages and the other problem was that the required NuGet packages weren't cached locally on my computer - if they were I believe it would work regardless of the faulty source.
It happens that I have a .NET 4.6.2 solution including Unit Test projects that builds just fine. However, when starting Live Unit Test it would complain build completed (failed) for some reason. Which is weird since the solution builds fine.
I started searching for the reason of this mysterious build failure. First thing to do is to enable verbose Live Unit Test logging: Tools/Options.../Live Unit Testing -> Logging Level. Once set to verbose it become obvious that Live Unit Test BuildManager had problems with some referenced third party assemblies, specifically (in my case) with NUnit and Moq. Errors were like this:
But why wouldn't it find these Assemblies where VS has no problem finding them. Note: I added these two (and other) assemblies through NuGet.
[09:02:50.728 Verbose] - BuildManager - MY_TEST_PROJECT_PATH\SomeFile.cs(1,7): error CS0246: The type or namespace name 'NUnit' could not be found (are you missing a using directive or an assembly reference?)
I went looking where the problematic references actually point (Solution Explorer, Test Project, References) and saw something odd. Instead of pointing to a some path under NuGet Packages directory they were pointing to build output directory. At some point in the past VS decided that it has to change the path to the assemblies for some reason. Probably it couldn't find them at original location and decided to find the only ones it could - ones from the recent build in the build output directory. Which is a bad move from Visual Studio and one that most certainly causes problems.
At the end the solution was rather easy once I discovered the reason. I simply upgraded NuGet packages to a newer version. Reinstall would also work.
Since last post about SharpRedux I added GettingStarted sample, did a bit of refactoring and added quite some documentation.
Go check the documentation and play with both samples.
Next step is to create a centralized hub for pushing actions and reading from into a visulizer. This will make visualizer and development of (mobile) apps much better experience. Also collecting history from apps running in the wild. Stay tunned.
I've been experimenting with a redux implementation for .net lately and here is the current state.
The core library is quite functional and ready for a bit more serious test drive. There is also a visualizer, redux based, and with a frontend for WPF (other frontends can be added).
Available are two sample apps, Todo which is a WPF/MVVM/redux implementation of TodoMVC. And a dirty Playground sample.
Here are two screenshots from Todo sample and a brief introduction:
The application itself is on the left while visualizer is on the right. Visualizer is further composed of actions list and state|difference display. Above it shows current state after highlighted action. Value " 1" in visualizer means list item with index 0 (when a list member) and item has an unique key with value 1 (when applicable).
Above the visualizer is showing state difference between the last action and previous one. You can also select any action from the list and click Reset to State which would rewind the state to one after that action.
But why would anybody bother with redux at all? The answer is logging, separation, unit testing and state rewind. Imagine you have an application that crashes - getting all the actions in proper order would give you the ability to reply exactly what user/application was doing until it crashed - even without any user intervention or feedback.
That's it for a quick introduction. I'll try to blog more, create more documentation about it, based also on feedback/interest. I'll try using it in a real project when an occasion appears. Also visualizer can be and probably will be improved. Right now is something that works well enough for start.
Righthand.SharpRedux is open source and hosted on github and libraries will appear soon on NuGet. You can also get the Todo sample as a zip (.net 4.6.2 required),
Immutable types are based on Righthand.Immutable which is also hosted on NuGet. Visual Studio 2017 extension that creates immutable code is available at Marketplace. Righthand.Immutable is optional for SharpRedux and can be used standalone.
I have an Xamarin iOS project and developing in Visual Studio 2017 and have app icons in an asset. Since I've upgraded to XCode 9/iOS11 the app icons aren't included anymore and Application Uploader would throw a ton of errors at me about the missing icons. Before XCode 9 it worked though.
Xamarin describes upgrading issues to iOS 11 here and there but nothing much for Visual Studio 2017 - a key is missing in Info.plist they say. But what key?
It turns out the solution is a really simple one. Open iOS project in Visual Studio 2017, open Info.plist in editor, go to Visual Assets and make sure that App Icons source is pointing towards correct asset (with app icons).
It will generate this Info.plist key and value (value might differ, based on where your app icons are):
This value can be added manually, as well, if you know what to add.
I recently tested a prototype of a Xamarin Android app that should run on Android 4.1+. So I fired up Visual Studio Emulator for Android and saw that API level 16 (4.1) is missing from the list. The oldest is level 17/4.2.
Since they have a nice smiley icon for feedback I wrote a quick request to include level 16 as well since a lot of apps are targeting 4.1+, not just me.
The shocker came few seconds later in a form of an automated e-mail response (emphasis mine):
Hello,Wait, what? First time I heard that VSE4A is no more. Which wouldn't be that tragic if Hyper-V wasn't involved. See, VSE4A is the only Android emulator based on Hyper-V. Why do I even care? Oh, I do and you should do as well. When Hyper-V is enabled it doesn't allow any other virtualization host to run. Sure, you can disable Hyper-V (reboot required) and go with Google's Emulator or a better one from Genymotion. But then you can't run Docker, Windows Emulator and your other Hyper-V guests at the same time. More here.
This is an automated message. Unfortunately, we have no plans to publish Android images past 4.4. We recommend that you try Google or GenyMotion’s emulator for future images of the Android operating system.
When we first released the Visual Studio Android emulator, the Google emulator was slow, out-of-date, and a significant source of pain for mobile developers. In addition to the great work performed by GenyMotion, the Visual Studio Android Emulator proved that emulators can be fast, productive tools for mobile development.
Since then, Google has responded to developer feedback by increasing their investment in their tools. The next generation Google Android Emulator has closed the feature gap that previously differentiated Visual Studio’s emulator. Google’s emulator has become much faster and more feature rich.
We also know that, for mobile developers, authenticity is key. We believe that Google, as the platform owner, is best positioned to provide ongoing support for new versions of the platform in a way that accurately and authentically reflects the real-world behavior on devices.
For developers like you who’ve come to love and depend on the VS Android Emulator, thank you! We will continue to support in-market platform images according to Visual Studio’s generous support policy. However, Microsoft will no longer produce new Android images for the VS Android Emulator. We consider this a successful project that has come to a natural conclusion.
Happy coding, indeed.
There is light of hope though. Miguel tweeted that there might be a solution in the future
Hopefully that's the case. In the meantime VSE4A still works and is available for download, it is just missing images, specially newer ones (latest is API level 23 aka 6.0).
But at the end I'd really like Microsoft to address the cause of this blunder: the monopolistic Hyper-V behavior on desktop. If Windows virtualization worked like others do ("live and let live") there won't be a problem whatsoever. The way it works now it makes sense on servers, not on desktops.
But instead of fixing that, Microsoft choose to create all imaginable emulators on top of Hyper-V. What could go wrong?
I’ve started experimenting with React and consequently Webpack. As a base I
picked Cory House’s excellent "Building Applications with React and Redux in ES6" course on Pluralsight (disclaimer: as a MS MVP I get free subscription). BTW Pluralsight is a really good learning content delivery - so much good stuff there.
Anyway, I was building upon Cory's project and at some time I decided to update packages to their latest version (by updating versions in package.json, deleting node_modules and running npm update). Everything went smooth except that I noticed that debugging in browsers stopped for some reason. Breakpoints weren't observed, sources weren't shown. The later proved as hint what to look for - devtool settings in webpack.config.js that is.
It turns out that Cory was using cheap-module-eval-source-map which was working with the original version of webpack. However after updating it didn't work anymore.
The solution is rather simple: add a new plugin to webpack.config.js:
Looks like that folks at webpack decided to put this functionality into a separate plugin at a certain point in time (I didn't follow its progress). And no, the solution isn't mine. Instead I found it at this stackoverflow thread.