Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 Monday, 26 October 2015

csla win8_fullMany people look at CSLA .NET and see a big, complex framework. And to be honest, this is an enterprise-grade framework that supports a lot of features, so it can be complex.

But it doesn't have to be, not for the simple scenarios.

So here's a basic walkthrough of creating a Web API service that sits on top of a CSLA business layer.

Remember: This exact same business layer can be reused (unchanged) to support everything from an iOS/Android mobile interface to a web interface to an old-fashioned Windows Forms interface. That is the power of CSLA .NET!

I should point out that even this code isn’t as simple as it could be – but I want to show a proper basic architecture that abstracts the interface, business, and data layers of the application. As a result you’ll end up seeing a number of projects created:

  1. Web API interface
  2. Business library
  3. Abstract data access layer
  4. Concrete data access layer

At the end of this process you’ll have a simple Web API service running. But even better, the projects/assemblies in number 2-4 are 100% reusable across other platforms.

You can get the finished code from GitHub.

1

To start, open Visual Studio 2015 and create an ASP.NET Web Application. I named mine SimpleService.

In the next dialog, indicate that you want to create a Web API style project.

snip_20151026135801

Using NuGet, add a reference to the CSLA-ASPNET-MVC5 package.

snip_20151026140340

2

Next, add a .NET 4.6 Class Library project to the solution. I named mine BusinessLibrary.

Using NuGet, add a reference to the CSLA-Core package.

snip_20151026140457

Also add a reference to the standard System.ComponentModel.DataAnnotations assembly. Thanks to CSLA .NET, the basic validation rules in this assembly not only work with ASP.NET, but also with every other UI technology, even on platforms where this assembly wouldn’t normally be available (like Windows Forms).

3

Now add a simple business class to the business library project. Add a class named PersonEdit.

CSLA supports editable and read-only objects, so I tend to name my classes XyzEdit and XyzInfo to differentiate easily between the type that supports changing data, and the type that typically shows a small subset of data when the user needs to see a list of data.

Edit the class to look like this:

using System;
using System.ComponentModel.DataAnnotations;
using Csla;
 
namespace BusinessLibrary
{
   [Serializable]
   public class PersonEdit : BusinessBase<PersonEdit>
   {
   } }

In the class add a read-only property and a read-write property as follows:

public static readonly PropertyInfo<int> IdProperty = RegisterProperty<int>(c => c.Id);
public int Id
{
   get { return GetProperty(IdProperty); }
   private set { SetProperty(IdProperty, value); } } public static readonly PropertyInfo<string> NameProperty = RegisterProperty<string>(c => c.Name); public string Name {
   get { return GetProperty(NameProperty); }
   set { SetProperty(NameProperty, value); } }

CSLA does include code snippets you can add to your project via the CSLA-Templates NuGet package. Here I’ve used the cslapropg and cslaprop snippets.

Finally, make the Name property required:

[Required]
public string Name
{
   get { return GetProperty(NameProperty); }
   set { SetProperty(NameProperty, value); } }

Note: CSLA .NET has a very powerful rule engine in addition to support of DataAnnotations attributes. The rules engine supports multi-property and multi-object validation, as well as authorization, and data manipulation/calculation. Basically, everything you need to implement virtually any business rule or process can be accommodated by the rule engine.

At this point the business domain class exists. But the only way to create an instance of an object is via the new keyword, and that’s problematic. You should generally use factory methods or dependency injection to create object instances. CSLA supports either, but the easiest approach is to use a factory method. Add the following method to the PersonEdit class.

At this point return to the Web API project and add a reference to the BusinessLibrary project.

    public static async Task<PersonEdit> GetPersonEditAsync(int id)
    {
       return await DataPortal.FetchAsync<PersonEdit>(id);
    }
#if !NETFX_CORE
    public static PersonEdit GetPersonEdit(int id)
    {
       return DataPortal.Fetch<PersonEdit>(id);
    } #endif

You will also need to add a using statement.

using System.Threading.Tasks;

The DataPortal is a CSLA concept that abstracts away creating, retrieving, updating, and deleting business domain objects so you can easily switch between different platforms (Xamarin, .NET, UWP, etc.) and also easily switch between 1-, 2-, 3-, and n-tier physical deployments of your application.

4

Now that the business domain class exists, let’s hook it up to a data access layer.

Add a .NET 4.6 class library to the solution. I named mine Dal.

This project will not contain the data access code, but will contain the definitions for all data operations, basically using a repository pattern. Inside this project I am not creating or using business domain types, I am creating and using data entity types. So where the business domain type created in the previous step is shaped to meet the needs of the interface (in this case the REST API), the types created in this Dal project will be primarily shaped to meet the needs of the database.

Add a data transfer type for person data to the project – a class named PersonDto.

namespace Dal
{
   public class PersonDto
   {
     public int Id { get; set; }
     public string Name { get; set; }
   } }

Add an interface named IPersonDal to the project.

namespace Dal
{
   public interface IPersonDal
   {
     PersonDto GetPerson(int id);
   } }

In a real application your interface would contain other methods as well that might allow other retrieval options, as well as the ability to insert, update, and delete a person data entity.

Next add a .NET 4.6 class library project to the solution named DalMock. This project will contain a concrete implementation of the data access layer we just defined.

Add a project reference from the DalMock project to the Dal project.

In this project add a class named PersonDal.

using Dal;
 
namespace DalMock
{
   public class PersonDal : Dal.IPersonDal
   {
     public PersonDto GetPerson(int id)
     {
       return new PersonDto { Id = id, Name = "Maria Kowalski" };
     }
   } }

Because this is a mock data access layer, it will just return hard-coded test values. You can also create another concrete data access layer project that uses EF or any other data access technology that you prefer.

Finally, the Dal project needs to provide an abstract/dynamic way to load the concrete data access layer assembly. Go back to the Dal project and add a class named DalFactory.

using System;
 
namespace Dal
{
   public static class DalFactory
   {
     public static T GetDal<T>()
     {
       Type dalType = null;
       if (typeof(T) == typeof(IPersonDal))
         dalType = Type.GetType("DalMock.PersonDal, DalMock");
       if (dalType != null)
         return (T)Activator.CreateInstance(dalType);
       else
         throw new Exception("DAL type not found");     }   } }

In a real application you would not hard-code the PersonDal type; instead you would load that type from a configuration file or through some other means. Or perhaps you’d use a full-blown DI container instead of this simple dynamic factory scheme. For this simple demo however, this code illustrates the concept behind dynamically loading a concrete DAL type.

At this point the data access layer itself is complete, so all that remains is to wire up the business domain class to the abstract DAL.

Go to the business library project and add a project reference to the Dal project.

snip_20151026144802

This provides the business domain classes access to the abstract concepts around the data access layer, without providing any access to a concrete DAL implementation.

In the PersonEdit class add the following method.

private void DataPortal_Fetch(int id)
{
   var dal = Dal.DalFactory.GetDal<Dal.IPersonDal>();
   var dto = dal.GetPerson(id);
   using (BypassPropertyChecks)
   {
     Id = dto.Id;
     Name = dto.Name;
   } }

This code interacts with the abstract DAL types in the Dal project, but ultimately invokes the concrete DAL implementation to get back data that is used to load the domain object with the values it needs to do its job.

Now all that remains is to create the REST interface.

5

Return to the SimpleService project and add project references to the Dal and DalMock projects. While the Web API project doesn’t technically need those references, it is critical that those DLLs end up deployed to the bin folder on the web server, and adding these references will cause Visual Studio to handle that detail on our behalf.

With that done, add a Contracts folder to the project. In that folder add a PersonContract class to the project.

namespace SimpleService.Contracts
{
   public class PersonContract
   {
     public int Id { get; set; }
     public string Name { get; set; }
   } }

This class defines the public contract for our API. You should never directly expose your internal business types to the outside world through a service; it is important to keep clean separation between the public interface and your internal implementation.

Next add a Person Web API controller to the project.

snip_20151026142818

using System.Web.Http;
 
namespace SimpleService.Controllers
{
   public class PersonController : ApiController
   {
     // GET: api/Person/5
     public Contracts.PersonContract Get(int id)
     {
       var person = BusinessLibrary.PersonEdit.GetPersonEdit(id);
       return new Contracts.PersonContract
       {
         Id = person.Id,
         Name = person.Name
       };
     }
   } }

This controller uses the factory method of the business domain object to retrieve the requested instance of the domain type. The data from that domain object is loaded into the public API contract type, which is then returned to the caller of the service.

Using this approach you have complete separation and maintainability over what the consumer of the service sees, how the internal business domain model works, and how the data access layer interacts with the database.

If the business layer implements business rules, such as authorization, at a per-property or per-type level, this service implementation would succeed or fail to return those values as it attempted to pull them from the business object. No rules are implemented in the Web API project, because it is part of the interface layer. All rules are implemented in the business layer.

You should now be able to run the Web API project and navigate to the service URL (the port number may vary).

http://localhost:59560/api/Person/5

The result should be JSON that looks like this.

{"Id":5,"Name":"Maria Kowalski"}

For more information about CSLA to go www.cslanet.com.

Monday, 26 October 2015 14:31:08 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, 22 October 2015

LSPK51I’ll be speaking at Live! 360 Orlando, November 16-20. Surrounded by your fellow industry professionals, Live! 360 provides you with immediately usable training and education that will keep you relevant in the workforce.

SPECIAL OFFER: As a speaker, I can extend $600 savings on the 5-day package. Register here: http://bit.ly/LSPK51Home

All roads lead to Live! 360: the ultimate education destination! Bring the issues that keep you up at night and prepare to leave this event with the answers, guidance and training you need.  Register now: http://bit.ly/LSPK51_Reg

Thursday, 22 October 2015 10:55:41 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, 21 September 2015

Universal-Windows-Platform-SmallI recently made an interesting discovery about Universal Windows Platform apps.

When you build and run them in Release mode they are compiled using the .NET Native compiler, and they stop using mscorlib.

Most of your common .NET types come out of mscorlib. For example:

System.Object, mscorlib, Version=4.0.0.0, Culture=neutral,PublicKeyToken=7ce85d7bea7798e

When you are running UWP code in Debug mode that remains true. But in Release mode the use of mscorlib is replaced by System.Private.CoreLib. For example:

System.Object, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

In the vast majority of cases nobody cares about the assembly qualified name of a type – unless you are using reflection, in which case you may easily make this same discovery.

In my case, working on CSLA .NET, this difference posed a real challenge. One of the key features of CSLA is the concept of mobile objects, where object graphs transparently flow (move) across the tiers of your application (between AppDomains, processes, or computers over the network). For this to work, the type names of the objects must be the same in the source and destination environments, whether that be an Android client talking to a full .NET server, or a UWP client talking to that same server.

Fortunately ever since ~2007 and Silverlight’s restrictions on reflection (and the fact that it didn’t support BinaryFormatter or NetDataContractSerializer) CSLA has had its own serializer: MobileFormatter.

MobileFormatter has some serious advantages over BinaryFormatter and the NDCS, most notably it works across all platforms in a consistent manner, as well as minimizing the use of reflection and providing substantial control over the format of the byte stream transferred over the network.

In this scenario that last point is important, because I was easily able to enhance MobileFormatter to translate any assembly qualified type name that uses mscorlib or System.Private.CoreLib so the assembly name is an arbitrary text code. I chose /n. The full assembly name becomes /n during serialization, and that code becomes the full assembly name during deserialization.

The result is that types flow between UWP and all other platforms (.NET, Xamarin, etc.) transparently - as always. As a bonus this change reduces the number of bytes transferred over the wire because the full assembly name isn't in the byte stream, just this short code.

I found that benefit to be compelling enough that while I was changing MobileFormatter to solve the mscorlib issue I also added code to translate the CSLA assembly name to /c in the same manner.

In the future I may look at ways to translate user-created assembly names (your business assemblies) into short codes as well, as that would save a lot of bytes on the wire.

Monday, 21 September 2015 15:47:28 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, 16 September 2015

Steps to repro the issue described in this github issue:

https://github.com/MarimerLLC/csla/issues/428

1. Pull the csla repo from
https://github.com/rockfordlhotka/csla.git

a. Switch to the NuGet-uwp branch
clip_image001

2. Open <root>\csla\Source\csla.build.sln

a. Build Release | All CPU
clip_image002

b. Don’t worry about the Xamarin projects – they don’t matter for this issue

c. Build results will be in <root>\csla\bin

i. including the problematic rd.xml files for the UWP projects

3. Open PowerShell, cd to <root>\csla\NuGet

a. Run ‘Build All.ps1’ /prerelease:Beta3

b. Run consolidatepackages.bat

4. Open <root>\csla\Samples\ProjectTracker\ProjectTracker.sln

a. Add a NuGet package source to <root>\Packages, for example:
clip_image004

b. Build Debug | All CPU

i. Ignore the async method lacks await warning – this is a testing artifact

ii. Ignore the warnings about our analyzers (unless you know how to fix them – this analyzer via NuGet stuff is challenging at best!!!!)

iii. You should end up with a build error:

Severity

Code

Description

Project

File

Line

Error

 

Payload contains two or more files with the same destination path 'Csla\Properties\Csla.Uwp.rd.xml'. Source files: C:\Users\Rockford\.nuget\packages\CSLA-Core\4.6.172-Beta3\lib\uap10.0\Csla\Properties\Csla.Uwp.rd.xmlC:\Users\Rockford\.nuget\packages\CSLA-UWP\4.6.172-Beta3\lib\uap10.0\Csla\Properties\Csla.Uwp.rd.xml

ProjectTracker.Ui.UWP

   

Wednesday, 16 September 2015 11:00:21 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, 04 September 2015

In a recent blog post @praeclarum discusses frustrations with NuGet 3.

His viewpoint is from someone who uses (used?) PCLs.

What is interesting is that I agree with him about NuGet 3, but my viewpoint is as someone who chose Shared Projects over PCLs.

So I rather suspect NuGet 3 solved some unknown set of problems that somebody must have had – but it wasn’t authors of libraries using and not using PCLs. Huh.

You might ask why I don’t use PCLs – and in particular in my CSLA .NET framework, which is extremely cross platform. And that’s actually part of the answer.

CSLA .NET came into being before .NET itself was released, and has been evolving ever since. Perhaps the biggest point of evolution occurred when I chose to support Silverlight 2.0 in around 2006 (or 2007?). That was the first point where the (then years old) codebase needed to stop depending on full .NET. Also at that point in time neither PCLs nor Shared Projects existed, but Linked Files existed (the precursor to Shared Projects).

As a result, much of the CSLA Silverlight code existed as links to files in the full CSLA .NET project. So there were two different projects – one for .NET and one for Silverlight. Shortly followed by a third project when .NET Server and .NET Client split.

Of course the .NET and Silverlight platforms weren’t the same, but by using linked files each shared file was compiled for each target platform, and we were able to use compiler directives to accommodate differences in each platform.

Any real-world project tends to end up with some cruft, and CSLA is no exception. By the time we’d followed this model to add Silverlight, Windows Phone, various versions of .NET (3.5, 4, 4.5), Xamarin (iOS and Android aren’t always identical either), WinRT, and mono we’d accidentally duplicated various files and inappropriately reused some compiler directives. I wish I could say the CSLA dev team was perfect at all times, but we take shortcuts, or miscommunicate, from time to time like anyone else.

Earlier this year I undertook a major initiative to shift all the linked files into a set of common Shared Projects using the official support provided in Visual Studio 2015. The end result is really nice, but this change brought me face to face with every compromise or mistake we’d made over the past several years. Fun!

The end result is that all the actual code for CSLA resides in a small set of Shared Projects, and those projects are shared into concrete compilable projects for each target platform supported by CSLA .NET. The release folder (compiler output target) looks like this:

snip_20150904183300

Then a set of NuGet 2 packages are created representing the various scenarios where people would want to use CSLA to reuse their business logic – across different user experiences and/or different platforms. The list of NuGet packages includes:

  • Core (basically Csla.dll for your platform)
  • Web (Core + Web (basic ASP.NET and Web Forms helpers))
  • MVC (Core + Web + helpers for the MVC version you are using)
  • WPF (Core + WPF helpers)
  • WinForms (Core + Windows Forms helpers)
  • WinRT/UWP (Core + WinRT and UWP helpers – which are the same right now thankfully)
  • Android (Core + Android helpers)
  • iOS (Core + iOS helpers)
  • Entity Framework (Core + helpers for the EF version you are using)
  • Validation (Core + helpers for enable backward compatibility with an older rules engine from CSLA 3.8)
  • Templates (installs VS templates and snippets on the dev workstation)

To accomplish this we have the following solution structure for the core Csla.dll outputs:

snip_20150904184309

Notice that there’s one Csla.Shared project – it contains all the code – and then a set of concrete compilable projects for the various platforms and .NET versions supported. Those projects contain no code at all, just settings for the compilers.

Would a PCL simplify this? Sort of, but not really. There are too many differences between some of these target platforms for the actual implementation code to exist in a single PCL. Remember, you can’t use compiler directives or have any platform-specific implementation code in a PCL – and that constraint is just too limiting to allow CSLA to do what it does. Perhaps this is in large part because a key feature of CSLA is that it shields your business code from underlying platform differences, so we can’t dumb down the code in CSLA and allow platform differences to penetrate our abstractions or we’d lose a primary benefit of CSLA itself.

Namely, you write your business logic one time and then reuse that exact code on every platform you want to target, thus radically reducing your maintenance burden over the years you’ll be running that code.

Now there is the concept of “bait-and-switch” with a PCL, where the PCL itself contains no implementation – only public interface definitions. And then you create a concrete compilable project with the actual implementation for each platform and .NET version you want to support. In other words, you do exactly what we are doing here, with the addition of one more project that only contains all the public class/interface/type information from Csla.Shared.

And I might do this “bait-and-switch” hack someday – but to make such a thing manageable I’d want a tool I can run as part of the build process that generates all that public type information from Csla.Shared, because otherwise I’d have to maintain it all by hand and that’s just asking for trouble. (anyone knowing of such a tool feel free to let me know!!)

We follow the same basic pattern for the various UI technologies – so there are a similar set of concrete projects and one shared project for XAML, Android, iOS, Web, MVC, etc.

The result is, in my view, extremely manageable thanks to the great support for Shared Projects in Visual Studio 2015. Yes, we’ve been following this approach “the hard way” since ~2007, so I feel very confident saying that VS2015 is a major step forward in terms of tooling around this model.

I also feel comfortable saying that I have no regrets that we didn’t go down the PCL route when PCLs were introduced. They’d have required we use the “bait-and-switch” hack, which is too much magic for my taste, and I think they’d have further increased the complexity of our solution.

Back to NuGet 3 – nothing I’m talking about here requires (or currently uses) NuGet 3. Part of the build process generates a set of NuGet 2 packages that I push into NuGet:

snip_20150904185812

As a result, when you add a reference to ‘CSLA MVC5’ you get the correct ‘CSLA Core’, ‘CSLA Web’, and ‘CSLA MVC’ assemblies in your project for the version of .NET your projects are targeting. Exactly what you expect. Easy for the end developer, and I think easy for us as maintainers of an OSS library.

From what I can see, NuGet 3 just changes a bunch of stuff and adds confusion to fix some problems I’m not encountering. That’s never a good sign…

Friday, 04 September 2015 18:01:31 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, 27 August 2015

csla win8_fullThis is a NuGet only release, we no longer supply an msi installer

Release details on NuGet: https://github.com/MarimerLLC/csla/releases/tag/v4.6.100

Supported platforms:

  • .NET 4, 4.5, 4.6
  • Android (Xamarin)
  • iOS (Xamarin)
  • UWP (Windows 10)
  • WinRT and WinRT Phone (Windows 8.1 and Phone 8.1)

Major changes:

  • Updated to the final release of Windows 10 and the UWP SDK
  • This and all future releases will be via NuGet only (no more msi installer)
  • Removes support for Silverlight and Windows Phone 8 (Silverlight)
  • Adds support for .NET 4.6
  • Adds support for UWP (though today NuGet deploys the WinRT assemblies for UWP projects)
  • Updates iOS and Android to the latest Xamarin versions
  • Move nearly all code files into shared projects
  • WinRT, iOS, Android, UWP all now use the exact same code files as .NET in every case - which is where a lot of the risk comes from because I may or may not have gotten all the compiler directives fixed up correctly.
  • Add analyzers for Visual Studio 2015 and .NET 4.6 projects
Thursday, 27 August 2015 08:40:34 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, 20 August 2015

Windows-10-logoIn a recent article ‘10 reasons you shouldn’t upgrade to Windows 10’ the author ends by saying that he did upgrade even over his own objections. I can’t argue with that conclusion, as my only remaining Win7 ‘machine’ is a virtual machine I use for legacy work, and I have no Win8 devices left at all (except for my phone, and hopefully I’ll be on Win10 there soon too).

Note: to be fair, @woodyleonhard wrote another article earlier on why you should upgrade to Windows 10.

I’ve upgraded or installed Windows 10 on quite a few devices at this point, and have been using it continually for a long time as part of the Windows Insiders Program. So I thought I’d provide at least some quick thoughts on the 10 reasons “not to upgrade” based on my experience.

10. Ongoing privacy concerns

I think there’ve been a lot of good rebuttals of this issue – not least of which is that anyone using an Apple or Android (or Windows) smart phone already gave away all their privacy anyway Smile

Perhaps more useful is this good article about what Windows 10’s privacy settings actually do.

9. OneDrive regression

There’s some truth to this – I liked the way Win8.1 did OneDrive. Apparently the Win8.1 approach confused a lot of people though – including several of my co-workers. OneDrive in Win10 now it works more like DropBox. I’m personally unconvinced that this is a big deal one way or the other.

For me the big thing was access to my massive library of photos in OneDrive, and when I discovered that the Win10 file open dialog (from Universal apps) can tap into the Photos app (and other file sharing apps like DropBox) to get at cloud-based files my life was greatly improved.

apps

8. Missing Media Center and DVD player

VLC (from the store, and for desktop), k-lite, and CCCP solve this problem just fine, in terms of playing DVDs anyway. I suspect that’s the biggest issue for most people.

If you are an actual Media Center user then I agree, don’t upgrade until you’ve found a replacement solution. You might consider one of the numerous other options that run on Linux and/or Windows.

7. Not much in the way of Universal apps

This isn’t new – there were relatively few good apps in the store for Win8.1 – and it continues to be frustrating into Win10. I really hope that the new UWP and UWP bridge technologies help bring a lot more apps to Win10. That, and the reality that there are nearly 100 million Win10 installs already (in the first few weeks the OS has been out) so you’d think that app authors would start to care about reaching this audience.

On the other hand, if you are a Win7 user then why would this be a roadblock to moving to Win10? You have zero apps in Win7, so what little is in the store is infinitely more than what you have today.

And if you are a Win8.1 user there aren’t less apps than what you have, there just aren’t really any more apps either.

6. Key apps, including Mail and Edge, aren’t ready yet

I’ll argue here about Edge, because I like it a lot. I know it doesn’t yet have some features of more mature browsers, but then again it is lighter and faster than they are and I like that trade-off.

On the other hand, the points about the Mail (and Calendar and People) apps are totally on point. I’m extremely disappointed that these apps weren’t (imo) completed before Win10 shipped, and every day when Mail crashes or messes up in other ways I wish for a higher quality app. They are getting better fairly rapidly, but today they are frustrating.

If you are coming from Win7 you don’t have these apps and so perhaps won’t care. If you have Outlook you won’t care, because you’ll probably keep using Outlook.

But I really, really liked the Win8.1 mail/calendar/people apps and can’t wait for the Win10 versions to catch up to their 8.1 predecessors.

5. Win10’s Tablet Mode may not appeal to you

If you are upgrading from Win7 you almost certainly don’t have a tablet, so moving to Win10 with tablet mode is immaterial because you’ll never use tablet mode. Not a roadblock.

If you are one of the few people that does have a Win7 tablet then how do you live with it??? And if you do, then Win10’s tablet mode with be nothing but an improvement. Again, not a roadblock.

If you are on Win8.1 with a tablet then Win10’s tablet mode is basically the same thing you have today. Nothing to lose in this case, but if you sometimes use a keyboard/mouse with your tablet then there is a lot to be gained by upgrading to Win10.

4. The installer may not be ready for you yet

Having upgraded quite a number of machines (including my father-in-law’s old laptop) without any issues I must say that Win10 is the first time in Windows history that I would recommend doing an upgrade rather than a fresh install. I’m amazed at the upgrade process and how well it works.

That said, if the installer isn’t ready for you it is probably because some hardware vendor for some component in your computer hasn’t released a Windows 10 driver yet. That’s increasingly rare, but if you are in that situation then you really don’t want to upgrade yet – not until the drivers are available.

3. Forced updates

I don’t really know what to say about this one. Not forcing updates is bad because people fall behind and end up vulnerable to viruses and malware, but forcing updates is causing some issues. It seems to me that the solution is to roll forward on the current course and for Microsoft to figure out how to make forced updates work reliably.

As (I hope) more apps end up in the Windows Store they’ll tend to only run on the current version of Windows, so not applying updates almost certainly means your apps will stop working. I personally use a lot of apps from the store, and I sure don’t want them to stop running because I missed an update!

2. Ain’t broke, don’t fix

This is somewhat short-sighted. I get the idea here, just like most people stick with old versions of OSX, iOS, or Android (note my sarcasm: most people don’t stick with old versions of those operating systems).

Enterprises being slow I understand, but most users of personal devices should just keep current in my view. Take advantage of the new shiny stuff, and stay with the most supported version of any OS to help avoid viruses and malware.

1. Questions, questions, questions

This isn’t a real point at all – just FUD because the author is (presumably) being paid by the word. Then on the next page he goes on to say that he upgraded anyway, because really, who wants to be stuck in the past when you have a free avenue into the future?

My conclusion

In summary, I haven’t hesitated to upgrade numerous computers to Windows 10, including computers for non-experts such as relatives and some friends. The transition from Windows 7 to Windows 10 is pretty easy for most people, it is much the same but a little prettier. The transition from Windows 8 to Windows 10 is nearly always an improvement – in desktop and tablet modes.

So yes, I am in favor of most people upgrading.

Thursday, 20 August 2015 11:49:12 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, 06 August 2015

After last night’s big cumulative update of Windows 10 one of my devices (my primary desktop) had some issues. Specifically, there were 4 apps the store wanted to update, but it seemed unable to download any of them (even after numerous reboots and running wsreset). And the Mail/Calendar apps were frozen; they’d launch but freeze.

The solution was in this article: http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_store/windows-10-store-beta-problems-wont-update/d7fe3b06-63e1-44c7-a5b0-2b8b6868e16d?auth=1 (followed by a reboot and then re-running wsreset).

My region/format setting in Control Panel (the old Win32 one) was set to the default:

region-start

And the fix was to change it to my explicit region:

region-fixed

To easily get to this dialog, press windows-x and select ‘Control Panel’. Then in the search box (upper-right corner) type ‘Region’ and click the one search result to open the dialog shown here. Then reboot.

Why this works I don’t know – clearly something gets confused deep inside Windows – but as long as the problem is solved I’m happy Smile

Thursday, 06 August 2015 09:43:19 (Central Standard Time, UTC-06:00)  #    Disclaimer
On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
November, 2017 (2)
October, 2017 (1)
September, 2017 (3)
August, 2017 (1)
July, 2017 (1)
June, 2017 (1)
May, 2017 (1)
April, 2017 (2)
March, 2017 (1)
February, 2017 (2)
January, 2017 (2)
December, 2016 (5)
November, 2016 (2)
August, 2016 (4)
July, 2016 (2)
June, 2016 (4)
May, 2016 (3)
April, 2016 (4)
March, 2016 (1)
February, 2016 (7)
January, 2016 (4)
December, 2015 (4)
November, 2015 (2)
October, 2015 (2)
September, 2015 (3)
August, 2015 (3)
July, 2015 (2)
June, 2015 (2)
May, 2015 (1)
February, 2015 (1)
January, 2015 (1)
October, 2014 (1)
August, 2014 (2)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2017, Marimer LLC

Send mail to the author(s) E-mail



Sign In