Mike-EEEMike-EEE

My feedback

  1. 491 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      24 comments  ·  Visual Studio IDE » Project  ·  Flag idea as inappropriate…  ·  Admin →
      Mike-EEEMike-EEE commented  · 
      Mike-EEEMike-EEE commented  · 

      Another issue has been opened in MSBuild, for those interested:
      https://github.com/Microsoft/msbuild/issues/613

      This captures some feedback worth exploring as well:
      https://github.com/dotnet/roslyn/issues/11263

      Mike-EEEMike-EEE commented  · 

      Nice conversation here, jump on in and let your voices be heard. :)
      https://github.com/dotnet/roslyn/issues/11235

      Mike-EEEMike-EEE commented  · 

      LOL @ Anonymous ... this is starting to remind me of the epic "YES!" "NO!" debate/rant/post fest that happened with bringing back Silverlight in Edge:
      https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8022150-run-xaml-c-like-silverlight-applications-ins

      The bottom line here is that there are two camps that MSFT has (unfortunately) created: web application developers and native application developers. Conceptually, they are one and the same (and ideally they should be!), but because of confusing/questionable strategy/direction we have now ended up with these two conflicting camps, with completely incompatible approaches and neither likes the ways of the other. Sounds like someone was inspired by our political system here in the US. :D

      Mike-EEEMike-EEE commented  · 

      There's been good feedback like yours Michael. Thank you for sharing and hopefully MSFT will consider this with its new project system. To start with, I am not sure how you don't think Xaml is not tool friendly while JSON is. With Xaml you only require two artifacts:

      1) Class definition (.cs file)
      2) Data file (.xaml file)

      Whereas with the JSON approach, you require 3:
      1) Class definition (.cs file)
      2) Data file (.json file)
      3) JSON Schema (yet another .json file)

      Then you need some way of linking up that 3rd schema file. JSON is supposed to be terse and standardized, but you end up having to define an arbitrary, unusual "$schema" attribute to point to its schema. With Xaml this is baked in to the root element and xmlns attribute and the tooling catches on to it without any sort of configuration.

      Don't get me wrong, I see, understand (I hope! :D ), and appreciate the value of JSON: for describing objects in a compact, human-readable manner that's intended to transfer across service boundaries. The fact that the standard doesn't support comments reflects this intent. Any extended use of this travels into dangerous territory as now you are violating/bending a "standard" that might further be used (read: copy/paste) down the line that ends up breaking in interoperable scenarios.

      At the end of the day, we have two developer scenarios: creating objects that are meant for transfer (lightweight/compact/terse: JSON is great for this), and defining applications that create those objects (significant/verbose: XAML is great for this). Of course, there are developers that prefer to keep the same format throughout their solutions to minimize context-switching and maximize efficiency, so this should be considered, too.

      As a business owner, I would prefer to have one language (C#) and one data format (Xaml) all the way through my solutions. That way, I not only have to worry about working with just these formats in any of my solutions (less time in context-switching) but I also benefit in seeking the resources from the marketplace necessary to manage/maintain them by was of a simpler more defined/exact skillset. Incidentally, this is another reason why I think it's so important for a consolidated, ubiquitous .NET client application model, as well:
      https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

      Mike-EEEMike-EEE commented  · 

      KEEEEEEEEEEEWWWWWWWWWWWWWWWWWWWWLLLLLLLLLL....
      From: https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

      "We also need to make it easy to work with projects across these application models. In order to do this we are working to merge the capabilities of .xproj/project.json and .csproj project systems into a single project system based on MSBuild."

      Sounds promising! And the right thing to do. :)

      Mike-EEEMike-EEE commented  · 

      Here's an article that sums up the discussion so far, discussing the tweet below, how Visual Studio is not actually following the .json specification, and screenshots/example of how Xaml is a viable object-definition language -- especially for things like project structure definitions:
      http://blog.developers.win/2016/02/has-the-tide-turned-on-project-json/

      Mike-EEEMike-EEE commented  · 

      Thank you john.ludlow.uk. Your support is much appreciated. :) Glad I am not alone here.

      FWIW, something to consider here. This seems to be speaking directly to project.json:
      https://twitter.com/joewalnes/status/696765701059670016

    • 2 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        I agree to the terms of service
        Signed in as (Sign out)
        You have left! (?) (thinking…)
        0 comments  ·  Visual Studio IDE » Version Control (Git/TFVC)  ·  Flag idea as inappropriate…  ·  Admin →
        Mike-EEEMike-EEE shared this idea  · 
      • 1 vote
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          I agree to the terms of service
          Signed in as (Sign out)
          You have left! (?) (thinking…)
          0 comments  ·  Visual Studio IDE » IDE and Editor  ·  Flag idea as inappropriate…  ·  Admin →
          Mike-EEEMike-EEE shared this idea  · 
        • 6,706 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            I agree to the terms of service
            Signed in as (Sign out)
            You have left! (?) (thinking…)
            under review  ·  292 comments  ·  Visual Studio IDE » .NET  ·  Flag idea as inappropriate…  ·  Admin →
            Mike-EEEMike-EEE commented  · 

            Correct, shimmy. All of the "Big Four" are accounted for, with the exception of the Web.

            I would also like to share my appreciation for your comment along with Lukas and Alberto's comment. And by appreciation I mean 100% agreement and shared vision. :)

            I also have to say I am a bit disappointed in //build and Evolve in that no cross-platform UWP was announced. Xamarin.Forms is a good stab, but has a lot of problems. I guess for the time being the best answer is Perspex, which is very much under development (and does not support web):
            https://github.com/Perspex/Perspex

            Mike-EEEMike-EEE commented  · 

            Pretty awesome... wonder if this can now be used to integrate WebAssembly somehow?
            http://mspoweruser.com/build-2016-microsoft-open-sources-xamarin-runtime/

            Mike-EEEMike-EEE commented  · 

            FWIW, this vote is mentioned in the following article: Azure, Xamarin, and ... a Ubiquitous .NET?
            https://blogs.msdn.microsoft.com/azuredev/2016/03/02/azure-xamarin-and-a-ubiquitous-net/

            Mike-EEEMike-EEE commented  · 

            Indeed, Eder! Very VERY happy about that -- to say the least! Cannot thank everyone enough, including the Visual Studio team -- assuming someone didn't hit the wrong button over there or something, ha ha!

            FWIW, here is a post I made about this very update here: http://blog.developers.win/2016/02/for-your-review-we-are-under-review/

            Totally more than I ever expected when I started this vote 4 months ago and I am forever humbled and honored by all that has transpired since then. FWIW, at *best* I was expecting to reach 1,000 votes after one year, let alone two months. Getting 2,000+ votes after 4 months has just rocked my world! And of course I was expecting like 4 or 5 *YEARS* to get *any* sort of recognition/acknowledgement from MSFT, so that has been wonderful as well.

            Granted, it's still just a simple update (without any explanation, no less) but to me that's like getting attention from the hottie in the room ha ha. Like I mentioned in other threads, I feel that question marks are starting to turn into exclamation marks and MSFT really is starting to feel like they are starting to move in the right direction again. :)

            Mike-EEEMike-EEE commented  · 

            Whoaaaa... thank you @Philippe Monteil for taking the time to elucidate this very new and emerging concept and technology. Outstanding, even! I do indeed think you have identified the preferred pathway here. I have known about WASM for a while now, but now that I have a better understanding of it I will be using it in my messaging going forward.

            Let's call it... WASM.NET! :D

            This pretty much sums me up right about now:
            https://media.giphy.com/media/75ZaxapnyMp2w/giphy.gif

            I would still like to prefer to think that transpilation-to-plain-old-JavaScript is a valid goal, as I (and many others) feel that is what MSFT should have done (or at least started working on) when they "strategy shifted" (or shafted, really) Silverlight back in 2011. I'm bitter and cannot let it go, I know. 5 years is a long time! You at least can run basic applications with modern hardware as JSIL/org has proven, and that is at least a better pathway than to simply tell developers to work instead with a completely incompatible language/model.

            OK I will now take deep breaths and count to 10. :P

            Mike-EEEMike-EEE commented  · 

            Well @Philippe Monteil now you have me confused. :P I thought WASM was interfaced via JavaScript?

            What is adding to my confusion here is that the creator of JSIL (http://jsil.org) is working on the CIL component for that project here:
            https://github.com/WebAssembly/ilwasm

            This is something I have known about for a while now, but my impression was/is that WASM is all JavaScript, and therefore a transpilation strategy would be the best way to interface with it.

            Please educate us, good sir. :)

            Mike-EEEMike-EEE commented  · 

            LOL @Marc Roussel! When a UserVoice thread becomes a product's tech support. ;) Marc, that looks like C# to me, albeit terribly formatted. Are you concerned about the [Ready] attribute?

            In any case, I am very appreciative of Bridge.NET supporting this cause and for sharing their project here and for the dialogue that has transpired here. @Philippe Monteil, that link is fantastic. Thank you. Easily the best article I have seen on WebAssembly to date.

            In any case, as the Developers Win! link below outlines, the Xamarin deal should take care of everything but the web. There indeed needs to be a solid pathway or, well, Bridge :) to get .NET into HTML5 browser-hosted scenarios via clever transpilation of JavaScript-to-.NET. It's a complex problem. JSIL.org has been at it for about 4 years now. It might involve multiple teams and technologies (like WebAssembly) to do it.

            The important and key part is to nicely integrate it with all the new stuff that MSFT/Xamarin are doing so that we are all one, big, synchronous, happy .NET family again. :) :) :)

            Once we have this solved it is going to be a golden -- nay, DIAMOND! -- era in Microsoft and .NET history, I dare do say!

            Mike-EEEMike-EEE commented  · 

            Exactly Scott... this definitely bodes well for our cause here. However, if only iOS and Droid are accounted for, and not browser-hosted scenarios, then NodeJS will still have a competitive, cost-effective advantage. It would be great to see the new Xamarin integration yield a new client application model that is based on a stronger Xaml offering (like WPF, NOT like UWP) and can compile/transpile for the big four: iOS/Droid/Windows and Web. :)

            Mike-EEEMike-EEE supported this idea  · 
            Mike-EEEMike-EEE commented  · 
          • 101 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              I agree to the terms of service
              Signed in as (Sign out)
              You have left! (?) (thinking…)
              23 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
              Mike-EEEMike-EEE commented  · 
              Mike-EEEMike-EEE commented  · 
            • 1,490 votes
              Vote
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                I agree to the terms of service
                Signed in as (Sign out)
                You have left! (?) (thinking…)
                193 comments  ·  Visual Studio IDE » Languages - Visual Basic  ·  Flag idea as inappropriate…  ·  Admin →
                Mike-EEEMike-EEE commented  · 

                Yeah... it still burns. Silverlight was really WPF that ran in a browser. It got killed because it really wasn't truly interoperabie/cross-platform. I think the dynamic now has changed in the marketplace we find ourselves in. We now have four platforms that have started to settle, and comprise ~3.5B devices: iOS (~1B devices), Droid (~1.5B), Windows (~1B with 270M announced yesterday being Windows 10), and the web, which is HTML5 these days and runs on all of the 3.5B devices in some form or another.

                Xamarin takes care of the native (non-web) scenarios, but the web continues to be a question mark. If WebAssembly turns out to be the answer then we really have a something to build towards.

                Or we can all just become NodeJS developers, as that works on all of the above scenarios today, without wait or hassle -- with the exception of working with JavaScript, that is. :P

                The good news is that MSFT is doing a good job of engaging its developers and is doing a better job of reading these UserVoice suggestions and the comments within them. I am cautiously optimistic. At the very least, we as .NET developers will have a solution that reaches all the native devices, at the worst, we will end up with two (incompatible) codebases like we have today to maximize market reach: .NET (native) and JavaScript (web). I really hope MSFT can find a way to realize the former.

                Mike-EEEMike-EEE commented  · 

                Cool... thanks for the context and information, @Sten2005. I fully hear/feel you on the abandoned worry. I'm a hardened (bitter?) Silverlight developer (from version 1-5), so I know all about that pain. What I see in .NET is that it is the most mature (and popular?) MSFT tech to date. My thought is that if MSFT were to push for one grand version of a platform that enabled every possible scenario -- not unlike what NodeJS currently enjoys -- and sticks with it offering full and committed support, then it would pretty much solve every known problem in its ecosphere.

                Then, using this (cross-)platform infrastructure, it could put any sort of technology it wishes on it, the most obvious being .NET and VB6.

                Big, impossible thinking, I know. LOL. But it would be cool to see. The goal being that you can start to invest with a MSFT technology and be assured that those investments will carry into the future without fear of abandonment and/or irrelevance.

                Mike-EEEMike-EEE commented  · 

                LOL @ "Xamarin dead end!" Funny. I am curious if someone can speak to why VB6 is preferred over VB.NET?

                If .NET was made so that you could build applications to run in a browser through the use of WebAssembly (more here: http://moduscreate.com/webassembly-explained/ ), would this also be an acceptable solution? I thought VB.NET was a better/next version of VB6?

                Mike-EEEMike-EEE supported this idea  · 
                Mike-EEEMike-EEE commented  · 

                *Somewhat* related vote:
                http://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

                Transpiling .NET artifacts into JavaScript/HTML5 has been going on for almost half-a-decade by some wizkid out of CA: http://jsil.org

                In my view, this is something an entire MSFT division should have been dedicated to doing, rather than some kid with lofty ambitions and a lot of spare time on his hands. It definitely should be a strategy and focus of MSFT going forward, and should expand into all areas of its technology IP portfolio, even VB6 if possible. :)

                (And yes, it should have DEFINITELY happened with Silverlight: http://dotnetfuture.wufoo.com/forms/m1azjhyi1ozawho/ )

              • 3,042 votes
                Vote
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  I agree to the terms of service
                  Signed in as (Sign out)
                  You have left! (?) (thinking…)
                  37 comments  ·  Visual Studio IDE » Mobile App Development  ·  Flag idea as inappropriate…  ·  Admin →
                  Mike-EEEMike-EEE supported this idea  · 

                Feedback and Knowledge Base