Microsoft brengt Visual Studio 2015 en .Net 4.6 uit

Microsoft heeft Visual Studio 2015 en .Net 4.6 uitgebracht. De grootste wijziging in Visual Studio is dat ontwikkelaars niet alleen apps kunnen maken voor Windows Phone, maar ook voor iOS en Android. Die ondersteuning maakt deel uit van de filosofie van Microsoft om een 'universeel platform' te bouwen.

Visual Studio 2015 en .Net 4.6 zijn sinds maandagavond te downloaden, meldt Microsoft. Alle wijzigingen voor Visual Studio staan in de changelog die het bedrijf ook online heeft gezet. Gebruikers kunnen vanuit Visual Studio apps ontwikkelen voor iOS en Android, waarbij de software ook een Android-emulator aan boord heeft op basis van Hyper-V en de beschikking heeft over debugtools voor de mobiele platformen.

Ook kan er met Microsofts programmeerontwikkelomgeving software voor OS X en Linux geschreven worden. Daarvoor kunnen de programmeertalen Python, ASP.Net of Node.js gebruikt worden. Gamedevelopers krijgen via Microsofts ontwikkelomgeving toegang tot engines als Unity en Unreal. Daarnaast brengt Microsoft ook .Net 4.6 uit, met onder meer ondersteuning voor http/2.

De Community-versie van Visual Studio 2015 is kosteloos, voor de Professional-editie moeten ontwikkelaars 1199 dollar, omgerekend momenteel rond 1107 euro, neertellen. De Enterprise-with-MSDN-editie kost 5999 dollar. Wie nu al de versie uit 2013 heeft, kan volgens Microsoft kosteloos updaten naar de 2015-versie.

Reacties (145)

[Sebazzz]

Eén van de, voor mij, meest interessante dingen is dat hier de nieuwe C# compiler in zit die in C# is geschreven. Dankzij de nieuwe C# compiler kan je eenvoudig, vanuit codeperspectief, inzicht krijgen in een codebase. Dit kan het bijvoorbeeld eenvoudiger maken voor auteurs van software libraries om 'diagnostics' met hun libraries mee te leveren die incorrect gebruik ervan detecteren en daarop waarschuwen. Ook kan dankzij de nieuwe C# compiler Microsoft sneller de taal laten evolueren.

Meedenken met wat er in C# 7 moet komen? Volg de discussies op Github!

[Reactie gewijzigd door Sebazzz op 23 juli 2024 03:38]

[atlaste]

Vwb .NET

Wat wellicht nog wel belangrijker is, is de nieuwe JIT compiler onder Roslyn. Oorspronkelijk is de .NET JIT'ter gebaseerd op de C++ compiler van Microsoft. Na versie 1.1 van .NET is de JIT'ter verder geoptimaliseerd op basis van dit raamwerk, pas nu is hier een nieuwe versie van uitgekomen.

Waarom is dit zo belangrijk?

Nou, in de begintijden van zowel Java als .NET was de 'opstartsnelheid' van een type een probleem. Tijdens het eerste gebruik van een type, moeten alle methoden in dat type worden omgezet in assembler. Dit moet echter heel snel gebeuren, wat betekent dat er relatief weinig kan worden geoptimaliseerd. Combineer dat met een C++ compiler die al bestaat en in de praktijk betekent dit simpelweg 'vrijwel geen optimalisaties'. Dat zie je heel duidelijk terug in de assembly code die door .NET wordt geemit (in Visual studio: ctrl-alt-D in je code), waarin geen gebruik wordt gemaakt van moderne SIMD/AVX instructies.

In de laatste jaren is dit minder een probleem geworden vanwege twee effecten: snellere processoren (maw: meer optimalisaties in dezelfde tijd) en nieuwe compiler-bouw technologieeen. Met name SSA compilation is qua technologie heel erg gegroeid en eigenlijk alle moderne compilers (zoals bijv. LLVM/Clang) maken hier gebruik van. De nieuwe JIT van Roslyn is (jawel) een SSA compiler, die from-scratch is gebouwd en open source beschikbaar is gemaakt: https://github.com/dotnet/coreclr .

Dit betekent concreet meer performance, meer samenwerking binnen het JIT team (voorheen was de x64 en de x86 JIT gescheiden; nu moeten ze per platform alleen een nieuwe emitter schrijven), een kleinere brug naar cross-platform LLVM (zie: https://github.com/dotnet/llilc ), een snellere cyclus naar updates (ze hoeven geen rekening meer te houden met het C++ team) en een kortere doorlooptijd voor bugs (om vele redenen).

Vwb C++

De C++11 ondersteuning in VS2015 is heel veel beter geworden dan de C++ ondersteuning in VS2013. Deze link vertelt wat details: http://blogs.msdn.com/b/v...atures-in-vs-2015-rc.aspx .

[roy-t]

Roslyn is inderdaad super interessant. Voor .NET developers een stuk interessanter dan iOS ondersteuning als je het mij vraagt .

Ook de nieuwe features van C# mis ik in het nieuwbericht. Er is echt ontzettend veel gebeurd in .NET land en dat komt nu allemaal tegelijkertijd samen in een nieuwe release van Visual Studio. Good times

[Reactie gewijzigd door roy-t op 23 juli 2024 03:38]

[MacD]

Ja, maar eindelijk hebben iOS devs een goede IDE ter beschikking!

[ProjWorld]

Wat maakt VS dan zoveel beter dan Xcode?

Volgens mij is Xcode sec zelfs een "betere" IDE, omdat VS niet kan compileren zonder Xcode (linksom of rechtsom...je hebt Xcode nodig.)
Daarbij komt dat Xcode voor Obj-C/Swift volledige code-completion biedt. Ik ken weinig mensen die met Xcode echt iets tekort komen, tenzij ze voor een bepaalde niche programmeren.

[atlaste]

Volgens mij is Xcode sec zelfs een "betere" IDE, omdat VS niet kan compileren zonder Xcode (linksom of rechtsom...je hebt Xcode nodig.)

Om helemaal fair te zijn moet hierbij vermeld worden dat dit niets te maken heeft met het goed of niet goed zijn van de IDE. Dit heeft te maken met het feit dat Apple het niet toestaat / mogelijk maakt om voor iOS te ontwikkelen zonder mac.

Het is juist dit soort 'vendor lock-in' op zowel software als hardware gebied die mij persoonlijk ontzettend tegenstaat. Microsoft laat de laatste tijd zien dat ze hier serieuze stappen in zetten. Ik zou het heel fijn vinden als Apple dat ook zou doen, o.a. met Xcode.

Daarbij komt dat Xcode voor Obj-C/Swift volledige code-completion biedt. Ik ken weinig mensen die met Xcode echt iets tekort komen, tenzij ze voor een bepaalde niche programmeren.

Nouja, "dezelfde programmeertalen gebruiken voor een grote variëteit aan platformen" lijkt me niet echt een niche te noemen.

That said, ik denk dat de keuze voor de juiste IDE voor een deel "smaak" is en voor een deel het verschil tussen rijden in een Porsche of een Golf. In beide gevallen kom je niet echt iets tekort, maar toch rijdt de Porsche lekkerder. Om dat goed te vergelijken zou je alle features naast elkaar moeten leggen... (Code completion zie ik eigenlijk als "noodzakelijke voorwaarde voor een IDE").
Ik heb jaren met beide IDE's gewerkt en mijn (niet op feiten gebaseerd) gevoel zegt me dan dat VS hierbij beter uit de bus komt dan Xcode. Maar om helemaal fair te zijn, dit zou je eigenlijk objectief moeten plussen en minnen.

[ProjWorld]

edit: Sorry, is laat. reply @atlaste

(Ik heb niet echt een voorkeur voor Xcode of VS, kies afhankelijk van mijn doelen wat bij me past en onderschrijf daarom ook je slotopmerking btw.)

Wil je niet met een diversiteit aan talen werken, dan ben je met VS evengoed gebonden aan de taalondersteuning/vereisten voor/op een specifiek platform.

Om bijvoorbeeld met C/C++ of Java een app voor GNU-Linux+Android+Mac+Win+iOS te maken, heb je zowel voor Xcode(7) als voor VS(2015) evengoed rekening te houden met de systeemafhankelijkheden/benodigdheden. Daar verandert een IDE niets aan de write-once-deploy/run-everywhere (of code-once-compile-everywhere) feature van een taal. De bibliotheken en/of SDK (als vereisten om die taal voor al die platformen te gebruiken) zijn voor beide IDE's meestal gelijk. Hetzelfde geldt voor JavaScript, python, C#, Gtk, Qt etc. Ik kan achterlopen, maar volgens mij zijn de meeste IDE's wel in te stellen/geschikt voor andere talen, mits de bibliotheken beschikbaar zijn.

Nouja, "dezelfde programmeertalen gebruiken voor een grote variëteit aan platformen" lijkt me niet echt een niche te noemen.

Ik weet niet of je bedoelt, dat ik het als een eigenschap voor een kleine doelgroep zou zien...niche is niche. Zegt verder niets over grootte...Voor wie het bovenstaande zoekt, behoort oa. tot niche "write once, deploy everywhere".
(Tenzij je doelt op .Net en het voordeel van meerdere talen voor verschillende delen te gebruiken en deze code uit te rollen naar alle platformen...Daarover later meer)

Om (voor 1 applicatie) verschillende delen met verschillende programmeertalen (bijvoorbeeld C, python en JavaScript) te gebruiken en deze in de nieuwe VS2015 te compileren voor alle platformen, wordt de programmeur verwend met VS2015...
True...Maar dan moet je wel rekening houden met de ondersteuning voor die platformen. Als ik de release notes voor 2015 goed interpreteer, is iOS nog steeds een no-go zonder resourcing door Xamarin. Succesvolle (foutloze) uitrol naar Android, iOS, Win en *NIX is afhankelijk van Mono/Xamarin en dat heeft weinig met VS als IDE te maken, maar meer met onderliggende/gebruikte interpreter-compiler.

Maar misschien wil je liever uitsluitend in 1 taal (C# /JavaScript bijvoorbeeld) programmeren, evt. voor een game icm. Unity? MonoDevelop heeft dan MIJN voorkeur boven Xcode (met C#-plugins)...Dat lijkt mij een vrij specifieke doelomgeving waar VS2015 OOK in opereert. Vandaar dat ik die Unity-keuze als niche benoem. Er zullen genoeg Unity devvers met andere wensen zijn, die een andere IDE of editor verkiezen boven VS/Xcode...

Feit is en blijft, dat zowel VS als Xcode voor crossplatform development/deployment (inclusief iOS-targets) genoeg alternatieven kennen voor specifieke situatie's.

[quote]"dezelfde programmeertalen gebruiken voor een grote variëteit aan platformen"[/quote]

Het gaat je om het gebruiken van .Net/Mono? ...Binnen mijn (kleine) kennissenkring programmeren we onderdelen ook lekker eigenwijs in verschillende talen en knopen we dit aan het eind van de rit in elkaar...Onze maintainer doet dit met Xcode en Mono en/of via Haxe en wij verwerken zijn output.

Misschien dat een professioneel-commercieel team het anders zou doen, maar aangezien wij niet afhankelijk zijn van code signing en approval door Apple om iOS apps uit te rollen (lees: Xcode is geen must, alleen als je via de App Store wil publiceren), zijn wij vrij in ons ontwikkelproces.

Dus als Xcode niet voldoet aan de wensen van een ontwikkelaar, hoeft dat niet aan de IDE te liggen. Sterker nog: dan heeft de ontwikkelaar waarschijnlijk een bepaalde functie van een specifieke taalbibliotheek (of framework) in gedachten waarvoor hij moet uitwijken naar een andere ontwikkelomgeving.

Zo switch ik klakkeloos naar MonoDevelop voor Unity op OSX Y of Win7 of Ubuntu, omdat ik snak naar C#-Unity code completion en Unity-integratie...Ik ben evengoed in staat om met Unity, Xcode in C# een game-applicatie af te leveren vanuit OS X naar (bijna) alle platformen. Als ik iets niet kan binnen Xcode in een zekere taal, is dat meestal omdat ik door voorkennis en gewenning niet verder kijk dan mijn neus lang is...

Ik snap heus wel, dat er legio voors en tegens zijn om allerlei argumenten, maar "beter" is zo'n achterhaald begrip als het gaat om programmeren en programmeeromgevingen. Als je iets kunt bedenken, is het waarschijnlijk wel mogelijk.

Dit draagt verder niet heel veel bij aan de nieuwswaarde over Visual Studio 2015 en .Net 4.6, maar afgaande op de resultaten van testruns met de Community variant in vergelijking met de trial van Enterprise (iOS/Android konden we niet testen) lijken de compiler-outputs met .Net 4.6 en 4.5.1 in VS2013 en 15 ook niet wezenlijk van elkaar te verschillen na decompiling/disassembly.

Wel lijkt het er op, dat je waarschijnlijk makkelijker port/hercompileert naar Windows 10. Of de Roslyn compiler daadwerkelijk bruikbare semi-universele (MSIL?) bytecode produceert, kan ik eerlijk gezegd niet beoordelen (veel compilerfouten en de code op GitHub is mij te complex om bruikbare aanwijzingen uit te destilleren). Ik denk dat onze eigen tools al te veel lowlevelcode verpakken in OO-achtige adressen, die zich niet goed lenen voor VS2015 om de ware krachten te tonen. Monaca/Cordova beloven in elk geval interessante vooruitzichten.

Anders dan het lang verhaal zou doen geloven, juich ik de innovatie van Microsoft wel toe...Ik ben alleen teveel vastgeroest in gewoontes om op korte termijn ervan te kunnen gebruikmaken.

[Reactie gewijzigd door ProjWorld op 23 juli 2024 03:38]

[atlaste]

[...] Voor wie het bovenstaande zoekt, behoort oa. tot niche "write once, deploy everywhere".

Nee, dat ben ik niet met je eens. Inmiddels vind ik dit meer een soort "fundamentele requirement" worden binnen de software industrie. Programmeertalen als C++, Java, c#, Javascript en zelfs HTML bewegen allemaal die kant op. Idem voor sofware libraries, voorbeelden zijn bijv. OpenCL, OpenGL, etc. Simply put: het is gewoon niet meer nodig en wordt ook steeds minder geaccepteerd door software developers.

Waarom? Simpel: ik wil niet dat mijn code het volgend jaar niet meer doet. Of dat hij volgend jaar niet meer onderhouden kan worden. Of dat ik specifieke hardware moet kopen van 1 manufacturer (IBM Mainframe...) omdat dit het enige is waar mijn software op draait. Of.. ik kan nog even doorgaan; bottom line: ik vind het niet meer te verkopen.

De grootste slag die hierin nog gemaakt moet worden heeft te maken met user interfaces. Met name HTML maakt goede slagen in de standaardisatie hiervan, maar ook Microsoft met XAML. Dat zie je ook sterk terug in het feit dat die dingen iedere zoveel jaar opnieuw worden geschreven.

Welnu, met de opkomst van tablets en smartphones gebeurde iets raars hierin. Tegen de trend in kwamen er weer platform-specifieke API's (iOS, Android en Windows Phone) EN allerlei low-level specifieke functies die sterk afwijken van de "normale" dingen (memory barriers op Android/iOS zijn bijv. heel anders dan op Intel/AMD). Voor een deel is dat gedreven door vooruitgang en moet je dus nieuwe dingen gaan ondersteunen (e.g. hardware half barriers), voor een deel is het gedreven door vendor lock-in praktijken (.g. geo-ceode API).

[...] Ik snap heus wel, dat er legio voors en tegens zijn om allerlei argumenten, maar "beter" is zo'n achterhaald begrip als het gaat om programmeren en programmeeromgevingen. [...]

Weet je... ik vind dat je hiermee te weinig respecteert dat Software Engineering een vakgebied is waar de afgelopen 30 jaar flink geinvesteerd is in de efficientie van software ontwikkeling. Naast de academische onderzoeken is voor bedrijven als Google en Microsoft iedere minuut die ze per dag kunnen besparen voor een softwareontwikkelaar miljoenen waard. Het proces dat beschrijft is om zoveel redenen op de middenlange termijn een slecht idee dat ik niet eens weet waar ik moet beginnen.

Als je dan vervolgens weer kijkt naar de "fundamentele requirement" van boven zie je wat het werkelijke probleem is. Het omgekeerde is het geval: je wordt door vendor lock-in geforceerd om op deze manier te werken, hoewel we allang weten dat dat niet zo'n goed idee is.

[...] lijken de compiler-outputs met .Net 4.6 en 4.5.1 in VS2013 en 15 ook niet wezenlijk van elkaar te verschillen na decompiling/disassembly.

Pro-tip: je kijkt naar de IL en niet naar de JIT output. IL willen we graag hetzelfde houden, indefinitely. De grootste inhoudelijke verschillen zitten in de JIT (RyuJIT).

[Carbon]

Het is juist dit soort 'vendor lock-in' op zowel software als hardware gebied die mij persoonlijk ontzettend tegenstaat. Microsoft laat de laatste tijd zien dat ze hier serieuze stappen in zetten.

Komt dat even goed uit dat voor Microsoft dat Apple de Swift compiler opensource gaat maken

Xcode voor windows zou een welkome stap zijn, maar ik zie het niet gebeuren.

Ik heb jaren met beide IDE's gewerkt en mijn (niet op feiten gebaseerd) gevoel zegt me dan dat VS hierbij beter uit de bus komt dan Xcode.

Ik werk dagelijks met beide IDE's en voor native iOS/OSX development is Xcode op dit moment gewoon de beste IDE ...en dat met ruime marge!

[Reactie gewijzigd door Carbon op 23 juli 2024 03:38]

[DrBreakalot]

Zelfs als de compiler open source is is xcode nog steeds nodig voor iOS apps. Volgens de voorwaarden van de app store moeten alle apps met xcode gecompileerd zijn.

Persoonlijk heb ik liever appcode dan xcode, dan heb ik ook iets aan de code completion.

[Carbon]

Zelfs als de compiler open source is is xcode nog steeds nodig voor iOS apps.

Klopt maar dat was niet mijn punt!!

btw Het probleem is ook niet Xcode maar dat je OSX en dus een Mac nodig hebt.

Persoonlijk heb ik liever appcode dan xcode, dan heb ik ook iets aan de code completion.

Met dat soort opmerkingen kan niemand wat.
Nu wek je de suggestie dat Xcode code completion niet werkt wat complete onzin is.

[Reactie gewijzigd door Carbon op 23 juli 2024 03:38]

[KingFox]

Wat ik me afvraag: hoe zit het op UI-vlak? Dat de achterliggende code in VS werkt op Android-iOS-Windows Phone allemaal goed, maar voor iOS maak je in Xcode simpel een responsive layout. Wordt dezelfde layout dan gebruikt voor Android en WP of hoe werkt dat dan?

Het grote voordeel van iOS vind ik net het responsive van de UI, iets wat me in Android van geen meter lukt. Zou handig zijn als je effectief in VS een keer je app maakt en gelijk kan uitrollen voor de 3 platformen.

[Reactie gewijzigd door KingFox op 23 juli 2024 03:38]

[zircondan]

Wat bedoel je met het responsive layout? Bedoel je hier websites of native apps?

Android is vanaf dag 1 bedoeld om layouts te maken die niet resolutie specifiek zijn en ik moet eerlijk zeggen dat ik met Android juist betere UI's kan maken die werken op verschillende scherm resoluties en verhoudingen. iOs had hiervoor geen last tot de komst van de iPhone 5 en nu de 6 en 6+.

[KingFox]

Welja als je in VS een applicatie maakt die je direct naar de 3 platformen kan exporteren, hou moet je dan een UI maken?

[vSchooten]

wat ik heb gezien is dat android gebruikt maakt van een "Layout markup en code in separate files" idee, xml voor de design en java voor de executie. Wat bij windows ook zo is maar dan uitgebreider (maar dus nog steeds redelijk te porten is) via WPF, deze heeft namelijk MVVM(Model View ViewModel) als ontwerp.

[Carbon]

ik moet eerlijk zeggen dat ik met Android juist betere UI's kan maken die werken op verschillende scherm resoluties en verhoudingen.

De iOS autolayout manager is vele malen flexibeler dan wat Android te bieden heeft,.
Probleem is dat het pas echt bruikbaar is vanaf iOS 7

iOs had hiervoor geen last tot de komst van de iPhone 5 en nu de 6 en 6+.

Je vergeet de iPad, ook voor de komst van de iPhone 5 moest je al rekening houden met device afhankelijke layouts

[Six9]

Als je een macmini in een kast zet en aansluit op je netwerk kan je hele team aan de gang.

Met Visual Studio is je bereik groter, de belofte van 1 keer schrijven overal op alle platforms uitzetten is nu echt mogelijk.

[ProjWorld]

edit: reply@Six9

Ik snap de twee punten en de relatie met mijn post niet zo...Het gaat om "beter"?

Ik begrijp dat het loont om code in 1x naar meerdere platformen uit te rollen en ik begrijp dat je met 1 ontwikkelmachine een team gelijktijdig kunt laten werken.

So? Plaats een willekeurig ander systeem in een netwerk en dan dan geldt het punt nog steeds. Of je nu met GameMaker/Unreal/Unity een spel of met Netbeans/Eclipse een bedrijfsapplicatie ontwikkelt.
In jouw voorbeeld werkt iedereen met VS (evt. alleen Xamarin .Net) en commit via netwerk naar Xcode op de Mac (heb ik ervaring mee). Dus iedere developer moet voor een tussentijdse build via het netwerk op de Mac testen. Als iedereen aan een ander segment werkt, lijkt me dat geen wenselijke situatie qua load. Dat voorbeeld kent dus wat mitsen en maren qua organisatie.

Java+Eclipse/Netbeans beloofden ook wat VisualStudio2015 nu beloofd te doen. Zolang er nog geen resultaten zijn, zijn dergelijke features nog geen feit. Het is geen feit dat VS2015 universele uitrol realiseert. Het wordt eenvoudiger/makkelijker/sneller...nl.:

Apple heeft/had Java ondersteuning ook beperkt voor de ontwikkelaars. Dat kan voor Xamarin-output ook gebeuren. Binnen de sandbox van iOS, zijn Microsoft, Xamarin, Sun etc. niet degenen, die bepalen wat wel of niet erbinnen draait.

Op dit moment (ik ben me ervan bewust dat er nog aan wordt gewerkt door Xamarin en Microsoft) developers):
Laat Xamarin Metal nou net statically compileren, dus 1x schrijven is waarschijnlijk afhankelijk van je ontwikkeldoel en het ontwerp, omdat je om diverse redenen JIT-code @runtime anders implementeert voor desktop en iDevice. Sterker nog: ook voor Android leunt VS2015 op Xamarin en die is niet threadsafe (little-endian ARM GNU/Linux ABI) voor armeabi en armeabi-v7a. Dit is niets nieuws en dit kom je ook in de release notes voor Visual Studio 2015RC en/of Xamarin Studio tegen...(bron moet ik even schuldig blijven )

Het wordt makkelijker om te publiceren voor meerdere platformen met vanuit een bepaalde broncode. Laten we wel een beetje de realiteit respecteren en Microsoft niet woorden in de mond te leggen.

de belofte van 1 keer schrijven overal op alle platforms uitzetten is nu echt mogelijk.

Er wordt beloofd dat een ontwikkelaar (met minder aanpassingen dan nu het geval is) meer broncode kan hergebruiken voor uitrol naar meer platformen, waaronder het eigen Windows 10. Dat is in elk geval een voordeel van het gebruik van VS over Xcode en ja, dan is je bereik inderdaad groter...Verder heb ik er geen waardeoordeel over, want ik niet kunnen ervaren/vergelijken hoeveel winst ik had kunnen behalen in vergelijking met mijn huidige setup.

Begrijp me niet verkeerd: VS heeft absoluut voordelen! Geldt echter ook voor Xcode, Eclipse-RoboVM, CodenameOne...etc. Ik kon echter ook zonder te testen al bedenken in welke situatie's Xcode "beter" was, maar dan was ik op voorhand al bewust van mijn doel.

Mocht het zo zijn dat VS2015 met elke willekeurige taal zonder enig voorbehoud of aanpassingen 100% herbruikbare broncode kon toepassen op de huidige systemen, als een soort C op steroiden, dan sloeg ik een maandje slaap over om meteen de betaalde API- en .Net framework-trainingen te volgen.

Na Java en C# ben ik iets kritischer met universele talen en IDE's...

[Reactie gewijzigd door ProjWorld op 23 juli 2024 03:38]

[hackerhater]

Wat mij niet duidelijk is dat of deze wijzingen ook gelden voor de OS X en Linux-versies van VS.
Zo niet is het maar van beperkte waarde.

[vinsterdamus]

VS code staat hier helemaal los van volgens mij. Wel zal de nieuwe versie van.net daar voor te gebruiken zijn. Al staat me iets bij dat daar .net 5.0 voor is en dat 4.6 nog Windows only is. 5 krijgt de voordelen van 4.6 ook ingebouwd

[hackerhater]

Dat vermoedde ik helaas al

[GekkePrutser]

Ik vind XCode anders ook niet slecht. Het is de laatste jaren erg vooruit gegaan. Wat is er zo veel beter aan Visual Studio?

[Six9]

1 keer schrijven voor alle apps op alle platformen inclusief het web. Zelfs voor applewatch...

[Carbon]

1 keer schrijven voor alle apps op alle platformen inclusief het web. Zelfs voor applewatch...

maw Compile once run anywhere.

Klinkt veelbelovend maar in de praktijk levert het subpar apps die niet de native look & fee en performance hebben van een native app.

Een ander nadeel is dat dergelijke apps standaard geen gebruik kunnen maken van platform specifieke mogelijkheden.
Daarvoor moet je een platform specifieke wrapper schrijven om de onderliggende API te koppelen met JS.

[Reactie gewijzigd door Carbon op 23 juli 2024 03:38]

[Six9]

Er zijn gewoon native tools in Apache Cordova en Xamarin voorhanden. Kijk de presentatie nog maar is na.
Dus ja 96-98% van de code is overal te gebruiken, de rest zijn keuzes om het native aan te passen.

[Carbon]

Er zijn gewoon native tools in Apache Cordova en Xamarin voorhanden. Kijk de presentatie nog maar is na.
Dus ja 96-98% van de code is overal te gebruiken

Xamarin is weliswaar native maar geen crossplatform oplossing ala Qt,HTML5/JS of Corona, er is domweg geen echte abstractielaag over het OS!

Het enige verschil is dat je praat met een C# versie van de platform API.
Je hebt dus nog steeds volledige kennis van de iOS en Android API nodig.

Dus ja 96-98% van de code is overal te gebruiken, de rest zijn keuzes om het native aan te passen.

Xamarin marketing bla bla..

Dat suggereert dat business logic >90% van de code beslaat, nou vergeet het maar! Bij de meeste mobile apps is de business logic amper 10-15% van de totale code-base.

[Reactie gewijzigd door Carbon op 23 juli 2024 03:38]

[Six9]

Heb je de key note presentatie bekeken of niet? De percentage die ik geef zijn Apache Cordova, ergens in de prestatie wordt een voorbeeld uitgelegd waar 2 apps worden gemaakt met Cordova tools. De ene app is voor verkopende managers en is op alle platforms zo goed als gelijk, omdat het door het hele bedrijf het zelfde moet werken. De andere app is voor consumenten en is compleet native, als je op een slider zoekt dan krijg bij Android een andere dan op iOS. Er zitten gewoon native tools in visual studio...

[MacD]

Alles. Codecompletion, code snippets, de hele layout, betere keyboardshortcuts, betere debugging integratie, plugins ...
En gewoon het feit dat je opWindows kan draaien en niet dat gedrocht Finder hoeft te zien.

Nadeel: iOS doet 'ie blijkbaar enkel onder Xamarin

[Carbon]

Codecompletion, code snippets,

Ik werk dagelijks met zowel Xcode als VS en op dat vlak kan ik geen van beide beter of slechter noemen.
Feit, met complexe C++11 code werkt Xcode codecompletion beter dan in VSS.

de hele layout, betere keyboardshortcuts,

Kwestie van persoonlijke voorkeur.

betere debugging integratie,

Ik geef je het voordeel van de twijfel, maw geef eens een voorbeeld.

En gewoon het feit dat je opWindows kan draaien en niet dat gedrocht Finder hoeft te zien.

ook hier, zoals je duidelijk laat blijken: kwestie van persoonlijke voorkeur.

Voor native iOS/OSX (Switft,C++,Objjective-C) development is Visual Studio nog geen serieus alternatief.
Daarvoor ontbreken een aantal essentiële features.

Een paar voorbeelden (willekeurige e volgorde):
Asset catalogs
Interface Builder (Storyboards, size classes, designable view classes)
iOS simulator/device debugging integratie
Drag & drop bindings (OSX)
Core Data modeler
Static analyser
Instruments toolset

[Reactie gewijzigd door Carbon op 23 juli 2024 03:38]

[MacD]

Ik geef je op vooral de laatstepunten gelijk. Sterker nog, je moet om met VS iOS/OSX te ontwikkelen met Xamarin werken (bah!), dus die optie gaat voor wat wij doen gewoon de deur uit. Laat staan mbt codesigning, key(s/management) en distributie, ik gok dat XCode daar verplichte kost voor blijft.

De punten waar je me 'het voordeel van de twijfel' voor geeft; layout is gewoonweg VRIJ in VS (en IntelliJ), waar XCode je vastlegt aan bepaalde posities (en zeer vervelend met multiple monitors).
Debugging, mijn hemel man! po VAR, wtf! Ontbrekende of onzinnige log statements!
En Finder? Cut/copy/paste. Het aanmaken van directories. Geen treeview (en de andere views zuigen allemaal op hun speciale manier, bv de Columns view waar je zo vervelend heen en weer door moet navigeren). Die belachelijke trashes en andere ._ bestanden! Het kost me seconden om op Windows/Linux iets naar een usb stick te schrijven, maar letterlijk minuten/tientallen minuten om dat op OSX te doen! Zelfs de (betaalde!) replacements zijn slecht. Oh, en die trashcan op m'n usb stick! WTF!?
Ik werk nu jaren met OSX en ben, ondanks alles uitzoeken, googlen en alle shortcuts opzoeken en leren, zeker 10% langzamer op OSX vergeleken met Windows. Dat is echt niet meer persoonlijke voorkeur meer.

Maaruh:

"Ik werk dagelijks met zowel Xcode als VS en op dat vlak kan ik geen van beide beter of slechter noemen.
Feit, met complexe C++11 code werkt Xcode codecompletion beter dan in VSS."

XCode is de laatste jaren beter geworden, maar dit kan je gewoonweg niet zeggen in mijn en te veel anderen hun ervaring. VS heeft jaren aan de top gestaan en doet dat nog steeds. XCode vs VS is ook nu niet een debat op het internet; VS wint nog steeds met gemak. Dat is echt iets waar MS, terecht en met success, vele miljoenen in heeft gestoken.

[Carbon]

waar XCode je vastlegt aan bepaalde posities (en zeer vervelend met multiple monitors).

Zelf ben ik nooit een fan geweest van de Windows MDI interface, maar goed persoonlijke voorkeur...

Debugging, mijn hemel man! po VAR, wtf! Ontbrekende of onzinnige log statements!

???

En Finder? Cut/copy/paste.

copy paste van bestanden werkt gewoon, alleen cut wordt niet ondersteund.

Het aanmaken van directories

Gaat niet moeilijker als onder Linux of Windows.

Geen treeview

OSX heeft heeft als z'n voorganger MacOS een treeview!
Nadeel van de Apple versie is dat deze ook de bestanden in de treeview toont, en dat is niet handig als een map veel bestanden bevat;

en de andere views zuigen allemaal op hun speciale manier, bv de Columns view waar je zo vervelend heen en weer door moet navigeren).

LOL Ik ken een Mac/Linux gebruikers die zweren bij de column browser!

Die belachelijke trashes en andere ._ bestanden!

Die ._bestanden zijn niet belachelijk maar worden gebruikt om HFS extended attributes op te slaan zodat deze niet verloren gaan bij het kopiëren naar b.v. een FAT32 filesystem.

[Gomez12]

Buiten persoonlijke voorkeur is er niet zo veel verschil, alletwee zijn ze volwassen en als de ene een nieuwe killer feature introduceert heeft de ander die de volgende versie ook.

[BoringDay]

Nooit en ten nimmer.

Embarcadero is al veel langer bezig met dit soort oplossingen (FireMonkey, C++Builder/DelphiXE) Delphi bestaat ook al veel langer dan VS en een stuk krachtiger.

Het idee is leuk en aardig maar je krijgt van die wrappers om libraries heen en de meest buggy oplossingen voorgeschoten (gare componenten sets, onder windows zijn daar best nogal wat van).

Bovendien heb je afhankelijkheid van de OSX/iOS/Android libraries/frameworks, kortom je loopt vaak ook nog achter de feiten aan.

iOS devs hebben al jaren een goede IDE -> XCode een omgeving die ervoor gemaakt is en geoptimaliseerd. (en voor android de zijne).

[MacD]

Ik ben het helemaal met je eens ... behalve de geschiktheid van XCode. Ik werk er jaren profesioneel mee en het blijft een middelmatige IDE. Android Studio (beter dan Eclipse, moet gezegd worden) is veel fijner om mee tewerken, maar het is al jaren zo dat Virtual Studio DE beste IDE is ... mits het ondersteunt wat je moet doen natuurlijk en zoals ik al poste, voor iOS moet je wel Xamarin gebruiken, wat idd veel wegneemt van wat je maakt voor iOS.

Maar ik zou het bijna op de koop toe nemen als ik nooit meer XCode hoefde te openen.

Al denk ik dat dat niet/nooit zal gaan mbt signing, licenties, uploaden, distributie van iOS apps etc etc etc.

[Carbon]

behalve de geschiktheid van XCode. Ik werk er jaren profesioneel mee en het blijft een middelmatige IDE. Android Studio (beter dan Eclipse, moet gezegd worden) is veel fijner om mee tewerken,

Toegegeven, de Android Studio editor (IntelliJ) is op bepaalde punten beter dan Xcode.
Echter...IDE is zoals de afkorting al zegt het hele pakket, niet alleen de editor.

In de praktijk (edit->compile->debug repeat)) is Android Studio gewoon minder productief dan Xcode. Daarnaast zijn de Xcode supporting tools (Instruments,Simulator) veel volwassener. (ik zeg het nog netjes)

[MacD]

Ik ben het met je eens met de simulator; de snelheid van command+r is geweldig en levert daadwerkelijk een bijdrage aan sneller ontwikkelen.

Maar Instruments vs de debugging in AS? De tools in AS zijn veel completer qua tracing en profiling, makkelijker in het gebruik en veel duidelijker. De stappen die je moet doorlopen om bijvoorbeeld orphans te vinden met xcode ... man, oh man. En dan moet je dat allemaal weer rechtzetten als je ze eenmaal gevonden hebt; de workflow van die instrumentatie is echt klote.

[player-x]

Wat ik denk dat het meest interessant is, is dat VS platform onafhankelijk is geworden, schrijf wat in VS, en je kan het uitbrengen op iOS, Android en WPxx.

Hiermee wordt VS de ontwikkel tool voor alle mobile apps, en daarnaast kan men die ook nog eens op de desktop Metro UI en Xbox draaien, ik kan het mis hebben, maar het zou best een kunnen dat hiermee, MS opeens nieuw leven in zijn App winkel heeft geblazen, en daar mee ook in zijn mobile OS Windows Phone.

[Reactie gewijzigd door player-x op 23 juli 2024 03:38]

[Carbon]

Hiermee wordt VS de ontwikkel tool voor alle mobile apps,

Nope, HTML5/JS apps hebben niet de look&feel/performance van native apps en sommige platform specifieke mogelijkheden zijn standaard niet te gebruiken.
Dat laatste is wel op te lossen via native code bridges maar dat moet per platform, en daarmee wordt het intiiele voordeel (write once run anywhere) )van HTML5/JS apps teniet gedaan.

[Reactie gewijzigd door Carbon op 23 juli 2024 03:38]

[Verwijderd]

Dat laatste hoor ik al jaren met de bijbehorende verschillende argumenten waarom dat een succes zou worden. Eerst zien. Dan geloven.

[BoringDay]

Hoe mooi het sprookje ook klinkt, uiteindelijk krijg je de beperkingen en wordt je met ongewenste oplossingen opgezadeld. Wil je het nog fatsoenlijk krijgen opgelost heb je vaak thirdparty-net-niet oplossingen en voor elke update kan je betalen.

Het lijkt mooi, maar staar je er niet blind op

[MacD]

Dacht ik ook ... maar niet dus. Voor Android/iOS werk je dus met VS via Xamarin. Driekwart van de apps die wij maken kan je dus niet maken met VS.

Waar ik van baal, want VS is echt een mooie IDE. Maar het zal Windows Phone echt niet redden (of zelfs uberhaupt iets uitmaken).

[KoalaBear84]

Inderdaad. Hier een mooie standaard-set met verbetering hulpjes m.b.v. Roslyn:
http://vsrefactoringessentials.com/

Deze werd getoond in de Release video, kende ik nog niet:
https://www.nuget.org/packages/Microsoft.AnalyzerPowerPack/

Enige die ik zelf dan niet prettig vind is dat er ook dingen in zitten die "var" aanraden, iets wat ik totaal niet leesbaar vind. Moet je telkens de hele regel gaan lezen, of zelfs nog dieper. Heb zelf daarom liever direct het goede type staan. #mening

[Reactie gewijzigd door KoalaBear84 op 23 juli 2024 03:38]

[Plekuz]

Je hoeft niet de hele regel te lezen, maar kunt ook met je muis over het var keyword hoveren om te zien wat voor type het is. Ikzelf heb er ook aan moeten wennen, maar vind het tegenwoordig toch makkelijker om var te gebruiken in plaats van op het oog redundante code in te moeten kloppen zoals:

Dictionary<string, int> myDictionary = new Dictionary<string,int>();

dan ziet voor mij persoonlijk

var myDictionary = new Dictionary<string,int>();

er toch een stukje overzichtelijker uit (ook mening uiteraard).

[Reactie gewijzigd door Plekuz op 23 juli 2024 03:38]

[Tux4life]

En toch heeft de eerste representatie ook z'n nut:

List<Integer> list = new ArrayList<Integer>();

(In java dan )

Als je allebei graag wilt kunnen uitdrukken, zou ik kiezen om het maar op een manier te doen, en wel de meest flexielebe.

Een sterk en afgedwongen typesysteem staat voor mij aan de basis van iedere goede programmeertaal. Er zijn zoveel bugs simpelweg niet mogelijk als de juiste types worden afgedwongen. Ook wil ik niet afhankelijk zijn van een goede IDE om dit soort basisfouten uit mijn code te halen

[Countess]

Die regel zou in C# nog minimaal een .tolist() aan het einde moeten hebben.

[Durandal]

Nee, die List<> in java is een interface, net zoals de IList<> in C#.
De ArrayLilst<> is een implementatie daar van dus je hebt geen ToList() conversie nodig.

Overigens hoef je sinds java 7 geloof ik de tweede typering niet meer te herhalen, dus:
List<Integer> list = new ArrayList<>();
is ook goed.

[Countess]

als het een interface is dan werkt het wel idd. (in C# begint elke interface met I dus dat had ik niet door)

maar dan kies je er expliciet voor om een object alleen via de interface aan te spreken. maar die conversie gebeurt in C# (en volgens mij java ook) automatische op het moment dat je dat object door geeft aan een functie of constructor die een IList verwacht.

kan me weinig redenen bedenken waarom je een object dat je zelf declareert en aan maakt in die zelfde functie alleen via een interface zou willen benaderen. je verliest niks door var te gebruiken.

[Reactie gewijzigd door Countess op 23 juli 2024 03:38]

[Durandal]

Ach, het is goed gebruik (i.i.g in java) om waar het kan de interface te gebruiken zodat je klaar bent voor toekomstige implementaties en je verantwoordelijkheden kan blijven scheiden.

Op lokale context heb je gelijk en is het meestal onzin maar het komt b.v. wel eenst voor dat je als interface-parameter van een methode een nieuwe implementatie verzint;

someObject.aMethod( new DoStuffInterface{
void interfaceMethod1(Param p){
// ad-hoc implementation of interface here
}
});

Je maakt dan alleen even een nieuwe lokale implementatie van de interface ipv een hele nieuwe class.
(hoop dat m'n haakjes goed staan )

[Verwijderd]

Er zijn dingen als explicit (conversion) operators. Op zich heb je gelijk, maar idealiter zou je nooit zelf een instantie aan moeten maken, maar dat door iets als bijvoorbeeld een Factory te laten doen. Enkel tegen interfaces aan programmeren heeft echt zijn voordelen; absoluut aan te raden!

[Verwijderd]

Deze simpele denkwijze zou ik proberen zo snel mogelijk af te leren. Wat vaak niet beseft wordt is dat er met de extenstion method ToList() op IEnumerable<T> een nieuwe instantie wordt aangemaakt en de inhoud wordt gekopieerd. Nu is dat misschien voor een lijstje niet zo erg, maar als dat in bijvoorbeeld een loop gebeurd kan het snel voor onnodige overhead zorgen.

Doe dit alleen als het echt nodig is, bijvoorbeeld als je niet zeker weet of er maximaal een keer overheen geïtereerd gaat worden (of weet dat er juist wel meerdere keren overheen geïtereerd gaat worden).

Deze vuistregel geldt trouwens voor bijna alle LINQ extension methods: handig en duidelijk, maar als het niet perse (in-line) hoeft, gebruik het dan niet.

[Countess]

dat zei ik dus voor ik wist dat List in java een interface is en geen nieuw object.

[Plekuz]

Java var werkt dan ook anders dan een var in C#. In C# (.NET) wordt var compile time al omgezet naar het juiste type, dus het juiste type wordt runtime afgedwongen. Het is puur een vereenvoudiging van de syntax tijdens het coderen.

[SPee]

In Java bestaat "var" als keyword niet !
Dus je moet het nog expliciet declareren.
(of ben je gewoon in de war met Javascript?)

[Plekuz]

Was niet wakker denk ik, javascript inderdaad.

[vSchooten]

Een sterk en afgedwongen typesysteem staat voor mij aan de basis van iedere goede programmeertaal.

Een programmeertaal is niet goed of slecht, het is een tool, ontwikkelt met een specifiek doel. Jij zou toch ook niet een hamer voor een schroef gebruiken? Het werkt natuurlijk wel maar het kan beter met een schroevendraaier gedaan worden.

Er zijn zoveel bugs simpelweg niet mogelijk als de juiste types worden afgedwongen. Ook wil ik niet afhankelijk zijn van een goede IDE om dit soort basisfouten uit mijn code te halen

Waarom laat je de IDE de typering regelen? Dat is gewoon lui, wij(mijn devteam) doen dat zelf via een code review...

[Reactie gewijzigd door vSchooten op 23 juli 2024 03:38]

[LOTG]

Ik ben het eens met weakling, heeft niets te maken met direct het goede typen maar gewoon om onnodig lange stukken flink in te korten. Het is ook gewoon safe om te gebruiken, aangezien het type gewoon bekend is en je ook gewoon kunt zien welk type het is met een mouse over.

Ik gebruik het ook erg graag in foreach statements.
En als je als je een beetje duidelijke naamgeving aan je variabelen geeft is het meestal daar ook nog wel in een oog opslag aan af te zien.

Dynamic daar en tegen, dat is iets waar ik op spuug. Dat is niet alleen onleesbaar maar ook nog eens rampzalig om mee te werken omdat je nooit zeker weet wat er uit komt. Vooral als je tegen een API aan zit te typen die je dynamics terug geeft, en het fijn misbruikt om er verschillende types door te drukken.

[kenneth]

Misbruik van dynamic is om op te spugen (maar dat geldt natuurlijk voor elk misbruik). Ik zou echt nooit meer met COM willen werken zonder dynamic.

[SG]

Waarom is er wel refactoring tool voor C# en VB maar niet C++ want dat mis ik eigenlijk. En ook goed book daar over.

[MSalters]

Simpelere talen, zonder backwards compabiliteit. C++ heeft redelijk te lijden onder de C compabiliteit, en het feit dat het teveel fases heeft (preprocessor, template compilatie, normale compialtie inclusief geïnstantieerde templates, linking).

[Verwijderd]

Helaas staat er niks in het artikel over web Development.
Microsoft heeft de gehele project structure omgegooid waardoor het mogelijk is om bijvoorbeeld node in de terminal te gebruiken. De structure is wel compatible met VS2013.

Verder is er voor web dev en Cordova een taskrun explorer toegevoegd van waaruit Gulp en Grunt tasks kunnen worden uitgevoerd. Deze is uiteraard uitbreidbaar. Zo heeft Mads Kristensen (leider van webtooling Visual Studio en ook bedenker Web Essentials en een bak andere extensies waar je niet meer zonder kunt na gebruik) support voor npm tasks gemaakt.
Mappen als node_modules en bower_components worden niet meer direct getoond, maar vallen onder resources in de solution explorer.
JSON schema support is direct ingebouwd (waar standaard de schemas uit schemastore.org worden gehaald), pretty file nesting (eerst een losse extensie van Mads Kristensen), EcmaScript2015 support, etc.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:38]

[R4gnax]

Helaas is wel de preview window functionaliteit voor output van Less of Sass compilatie naar CSS en CoffeeScript compilatie naar JavaScript komen te vervallen als onderdeel van de WebEssentials extensie.

Deze zou "vermoedelijk op een later tijdstip" herintroduceerd worden als onderdeel van Mads Kristensen's WebCompiler extensie.

De mensen die de volle featureset van Less gebruiken (zoals ik) zijn alleen wel het haasje; Mads is hierin afgestapt van het gebruik van NodeJS en de officiële lessc compiler en gebruikt hij nu de dotless compiler: een alternatieve compiler voor Less, geschreven in C#.

Dat project bestaat al een flinke tijd en huppelt na al die tijd nog steeds hopeloos achter de feiten aan: het loopt ettelijke major revisions achter op de officiële lessc compiler waardoor zowel 'nieuwe' taalconstructies (als je detached rulesets nieuw wilt noemen) als nieuwe functies uit de standaard functiebibliotheek van Less niet ondersteund zijn en sommige wel ondersteunde taalconstructies en functies produceren andere output als de officiële compiler.

Een preview venster wat iets anders toont dan wat er daadwerkelijk geproduceerd gaat worden door de nieuwe grunt/gulp (en dus ook lessc) toolchain: lekker nuttig. Als je veel doet met Less, zul je dus kennelijk naar een andere oplossing moeten uitwijken voor IDE support.

Stilstand is achteruitgang, maar kennelijk is ook vooruitgang soms achteruitgang...

[Reactie gewijzigd door R4gnax op 23 juli 2024 03:38]

[Verwijderd]

Het probleem met de Less compiler, sass compiler, etc was dat deze via Node draaide. Node crashde simpelweg te vaak waardoor soms heel visual studio onderuit getrokken werd. De meeste crashes van WebEssentials2013 werden ook door node veroorzaakt.

Verder is het lastig om zomaar een preview van een bestand te tonen omdat er van alle kanten dingen geincluded worden, etc.

Er is voor gekozen, helemaal na het invoeren van de task run explorer en de verandering van de project structure om gebruik te gaan maken van task runners als Gulp en Grunt. Deze geven veel meer flexibiliteit, zorgen dat iemand met Atom, Sublime, etc en op andere platformen je project ook kan gebruiken en niet afhankelijk is van VS. Belangrijkste punt imho vind ik nog wel dat het hele web aan het veranderen is naar builden met deze task runners.

Helaas wilt niet iedereen deze task runners gebruiken. Daarom zijn de twee extensies Compiler en Minifier gemaakt.
Zoals ook in Github is te lezen bij de respectievelijke repos, is het heel lastig om een goed werkend preview pannel te implementeren.

Er is voor .NET / C# versies gekozen, omdat deze via C# kunnen worden aangesproken. Extensies worden ook weer in C# gemaakt. Het geheel is dus veel stabieler. Aangezien de extensie en de libraries oss zijn, kun je uiteraard altijd de missende features toevoegen (:

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:38]

[R4gnax]

Het probleem met de Less compiler, sass compiler, etc was dat deze via Node draaide. Node crashde simpelweg te vaak waardoor soms heel visual studio onderuit getrokken werd. De meeste crashes van WebEssentials2013 werden ook door node veroorzaakt.

Ten eerste draait met WebEssentials 2013 de Node.js executable als een apart, compleet lossstaand process naast Visual Studio. De communicatie tussen de WebEssentials extensie in Visual Studio en het deel wat in Node.js draait vindt plaats via een network connectie over de local loopback.

Als Node.js zou crashen, dan zou dat hoogstens dat ene losstaande proces doen crashen en niet heel Visual Studio. Web Essentials 2013 zit zelfs zo in elkaar dat het een nieuw node.exe proces start als het oude niet meer draait wanneer het van de functionaliteit die onder NodeJS draait, gebruik moet maken.

(Ik heb voldoende malen de node.exe die aan Web Essentials verbonden zat met de hand via task manager afgeschoten omdat ik wijzigingen had gemaakt aan een plugin voor de Less compiler die ik even wilde testen.)


Weet je waardoor Web Essentials vaak crashte? Door domme programmeerfouten van Mads Kristensen in de tekst editor afhandeling.

Zaken zoals de return waarde van functies waarvan gedocumenteerd is dat ze null mogen teruggeven niet checken op null waardes, maar blind gebruiken;

of off-by-one fouten maken wanneer je karakterreeksen uit de buffer van de teksteditor van Visual Studio wilt ophengelen en gebruiken;

of een tekstspanne blind aan proberen te passen, zonder te checken of de class die die spanne representeert deze als read-only gemarkeerd heeft staan.

Hier is er bijvoorbeeld weer ééntje:
https://github.com/madskr...ssentials2013/issues/1918

[Reactie gewijzigd door R4gnax op 23 juli 2024 03:38]

[Verwijderd]

Ik weet dat Microsoft bezig is met een Node wrapper voor hun Chackra engine. Chackra word dan ook weer voor de javascript Intellisense gebruikt. Denk dan ook dat het een goede zet zou zijn als Node via de wrapper in Visual studio word ingebakken. Kunnen een hoop mooie extensies mee gemaakt worden. Bijvoorbeeld de fatsoenlijke compilers gebruiken, maar ook de Node dev environment verbeteren.

Over de kwaliteit van Mads' code, hij heeft zelf ook aangegeven (tijdens Build 2014) dat je zijn code niet in Visual Studio wild. Hij geeft dus al aan dat zijn code niet om naar huis te schrijven is.
Hij staat bij mij ook een beetje heel erg bekend als degene die met goede (sommige zelfs onmisbare) extensies komt, alleen is de code niet super degelijk, snel in elkaar geknutseld en mist het Unit Testing (word dan als issue geplaatst wat de community mag doen...).

Zijn ideeën zijn goed, alleen zoals je zelf ook al aangeeft alles behalve goed uitgewerkt.

[Six9]

Het artikel is bewust klein gehouden omdat het teveel omvattend is en de achtergronden niet begrepen worden. Wees blij dat er wat gepost kan worden😉

[capsoft]

1 uur 44 min en 56 sec duurt deze keynote van gisteren
https://channel9.msdn.com...015-Any-app-Any-developer
sprekers:
S. Somasegar, Scott Hanselman, Brian Harry, Beth Massi, Amanda Silver

[Left]

En ook niet helemaal onbelangrijk: samen met Visual Studio 2015 heeft MS ook TypeScript 1.5 gereleased.
http://blogs.msdn.com/b/t...ncing-typescript-1-5.aspx

[qbig1970]

Leuk dat Microsoft .NET 4.6 uitbrengt, maar waar haal ik het vandaan???
Gaat het via Windows Update?
Ik kan ook niks vinden in de Microsoft Download Center!
Of wacht Microsoft met het uitrollen, om het slipstreamed in Windows 10 samen te brengen?
Het laatste lijkt me wel handiger.

[Reactie gewijzigd door qbig1970 op 23 juli 2024 03:38]

[CriticalHit_NL]

Heb even rondgezocht via google, dit zijn de links:

Online Installatie: http://go.microsoft.com/fwlink/?LinkId=528259
Offline Installatie: http://go.microsoft.com/fwlink/?LinkId=528233
Windows RT: http://go.microsoft.com/fwlink/?LinkId=528255
Windows RT 8.1: http://go.microsoft.com/fwlink/?LinkId=528256

Komt van deze pagina vandaan:

https://support.microsoft.com/en-gb/kb/3045560

Maar deze laadde niks bij mij dus maar de cache gebruikt van Google:

https://webcache.googleus...&cd=1&hl=nl&ct=clnk&gl=nl

[Reactie gewijzigd door CriticalHit_NL op 23 juli 2024 03:38]

[geertdo]

Oef... https://www.visualstudio....download-visual-studio-vs

[DedSec85]

Wel gaaf dat je nu iOS apps kunt bouwen in Visual Studio. Voorheen was het hebben van een Mac echt noodzakelijk. Ik was de laatste tijd al wat met Swift aan het experimenteren in Xcode maar ga zeker deze week Visual Studio uitproberen.

De laatste keer dat ik Visual Studio gebruikt heb was in mijn HBO periode. Volgens mij was dat Visual Studio 2003. Lekker lopen spelen met C# en ASP.net. Jammer genoeg daarna het programmeren een beetje laten varen....

Dit is wel een mooie gelegenheid om het weer op te pakken

[ThaStealth]

Helaas, je hebt nog steeds een Mac nodig voor te compileren (voor de iOS App). Het volledige schrijven kun je wel vanuit Visual Studio doen

[Reactie gewijzigd door ThaStealth op 23 juli 2024 03:38]

[Verwijderd]

Visual studio heeft nu toch een objective-C compiler

[ThaStealth]

Dat klopt, maar van Apple moet je met de source met een Mac compileren, signen en deployen....
Gelukkig kun je wel Xamarin Build Host installeren op de mac, zodat je zoals Six9 schrijft alleen maar de goedkoopste mac nodig hebt en die in een bureaula kan mikken.

[SG]

Mac heb ik nog niet maar wel wat iGadgeds met IOS.
Maar ik vraag me af als je het onderste uit de kan wilt halen met een IOS game dat je dan Metal API moet gebruiken en dus meer native met platform bezig moet zijn.

[ThaStealth]

Als je crossplatforms games wilt ontwikkelen moet je niet de VS2015/Xamarin combinatie gebruiken, maar kun je beter een engineer zoals Unity gebruiken

[SG]

Het hoeft voor mij nog niet crossplatform. Eventueel een aparte port voor alleen IOS.
Ik heb 3 projectjes. Een app, game en app.
De 2 appjes zijn met ook visualisatie deel. Dat kan ook met moderne OS GUI API,nog niet aan toegekomen. Maar dat vind ik zoon monster. Ik werk juist liever met strings dan char. Maar moet dus frequent van core app van string naar char omzetten omdat GUI functies dat gebruiken als parameters. String is wat heavy weight. Maar voor mijn lichte appjes niet zoon probleem.
De 2 de is een zeer crude prototype space game met als bases een DX11 demo.
De laaste Appje heb ik van de game project een branch off gemaakt en dat appje is dus met DX 11. Tja de visualisatie aandeel gaat met 3D rendering uiteraard beter. Alleen moet ik de GUI zelf verzinnen.

Voor IOS port zou ik dus native porten naar de grafische omgeving.
Gezien ik DX gebruik. Maar dat is van veel latere zorg. Blijf toch voorlopig puur op windows. En refactor ik het DX aandeel beperkt tot de visualisatie module. Met mogelijk porten in gedachte.

[Six9]

Ik heb een oude macmini in de meterkast staan werkt perfect.

[raymens]

"voor de Professional-editie moeten ontwikkelaars 1199 dollar, omgerekend momenteel rond 1107 euro, neertellen."

Dat is niet waar, Professional kost $499. De versie van $1199 is inclusief MSDN wat niet duidelijk wordt aangegeven.

Zoals te zien op:
http://www.microsoftstore...-2013/productID.284832200

Update:
Linkte inderdaad 2013, excuses. Verwacht overigens niet dat 2015 veel duurder zal worden.

[Reactie gewijzigd door raymens op 23 juli 2024 03:38]

[AirJonn]

Dat is versie 2013, waarvan ik vorige maand 2 licenties heb gekocht, benieuwd hoe dat zal upgraden

[Phyxion]

Voor zover ik begrepen heb, de versie met MSDN krijg een gratis upgrade, anders zal je hiervoor moeten betalen.

[Adion]

Helaas is Visual Studio 2015 nog niet beschikbaar daar.

[DerDee]

De losse VS2015 pro versie zonder MSDN zal later volgen en op TechDays dit jaar werd verteld dat de prijzen omlaag zouden gaan, ik reken dus op een bedrag tussen $400-$500.

[SG]

Ja ik heb de Pro 2012 versie zonder MSDN.
Kijk ook uit naar die versie. Maar check uiteraard wel even de verschillen of het veel uitmaakt.
Het is voor hobby.

[Titan_Fox]

Ik ben benieuwd hoe lang het duurt voordat deze versies naar Linux worden gebracht. Vond het destijds erg positief van Microsoft dat ze het .NET framework ook voor Linux hebben uitgebracht. Nu kan ik wel vanuit een VirtualBox gaan werken, maar een native versie is toch wel een stuk comfortabeler.

[sjongenelen]

Je bedoeld de versie van VS? Ik weet wel dat ze Visual Studio 'Code' hebben uitgebracht; een IDE voor op non windows devices. Het schijnt niet écht VS te zijn, maar wel een fijne editor.

Verder werkt het Core CLR van .Net framework inmiddels op meerdere platforms en zijn ze bezig met het verder uitbouwen hiervan. Top ontwikkelingen binnen Microsoft

[Jorick]

Visual Studio Code is gebaseerd op Atom van Github maar heeft IMHO weinig van doen met Visual Studio en ik snap ook niet echt waarom ze het die naam geven. VSC is (op dit moment) alleen gericht op web- en cloudbased ontwikkelen, voor .NET ben je op dit moment aangewezen op MonoDevelop als je OSX of een linux distro gebruikt.

[Bamsebjorn]

Het kost wat werk, maar ik gebruik VScode op Windows, Linux en Mac voor een Mono/.NET project. Met behulp van tasks kan je VScode alles laten doen.
Op Linux en MacOS X kan je zelfs Mono applicaties debuggen.

[GrooV]

Inmiddels is Visual Studio Code gelanceerd welke wel op Linux werkt (Aangepaste Atom + Omnisharp + vnext)

[Verwijderd]

Visual Studio Code gebruikt geen aangepaste versie van Atom! Ze gebruiken Electron (eerst Atom Shell) wat niets meer is dan een samenvoeging van node en chromium embedded framework met wat extra logic toegevoegd. Verder heeft microsoft zelf een complete editor gemaakt met TypeScript. Atom is geschreven in CoffeeScript.

[Sebazzz]

Visual Studio zal nooit op Linux werken. Dat is simpelweg technisch niet mogelijk. Het is een jarenoude applicatie, geschreven in C# en C++. Het maakt gebruik van COM, wat een Windows concept is, en van WPF wat eveneens niet op Linux bestaat.

[Relief2009]

Nooit is wel een heel sterk woord. Alles is mogelijk. Het is een kwestie van of Microsoft wil. En die zullen wel moeten willen ze cross-platform domineren.

Let maar op, de volgende versie zal ook op Mac en Linux draaien.

[NicoJuicy]

Volgens mij was WPF niet mogelijk op Linux (geen ondersteuning vanuit Mono, het project is te groot en de interesse te laag), als Visual Studio daarop gebaseerd is. Dan gaat het gewoon niet

[hackerhater]

MS wilde toch .net cross platform maken? Kwestie van WPF ondersteuning daarin zetten en klaar.
Kan niet is bullshit. Of ze het willen doen is een tweede.

[NicoJuicy]

Zoals ik al zei: het project is te groot en de interesse te laag

[Sebazzz]

Je gaat niet cross-platform domineren door je ontwikkeltools cross platform te maken. Microsoft heeft Visual Studio code released. Dat is hun cross platform ontwikkeltool - hoewel wel meer op ASP.NET gericht en dat sterker en populairder te laten worden.

Visual Studio gaat nooit geport worden, ik denk dat je onderschat hoeveel werk dat is.

[SuperDre]

VSC is dus de basis waarmee MS begint, uiteindelijk zal die gewoon uitgebreid worden met de functionaliteiten die nu beschikbaar zijn in de gewone VS..
Sowieso is MS ook steeds meer bezig om VS naar cloud te brengen (niet dat ik dat echt fijn vind werken op het moment), dus uiteindelijk is het heel goed mogelijk dat er geen 'normale' VS meer komt..

[Verwijderd]

Ik denk dat deze Visual Studio versie meer op het ontwikkelen van universal apps gericht is dan op het ontwikkelen van ASP.net

[LOTG]

Gamedevelopers krijgen via Microsofts ontwikkelomgeving toegang tot engines als Unity en Unreal.

Wat bedoelt Tweakers nou hier mee? Ik kan nergens iets vinden dat dit nu native ondersteunt word, en het kon ook al in VS2013. Voor Unity moet je UnityVS installeren, net zoals bij VS2013.

Iets anders wat ik niet terug lees in het artikel.

Visual Studio Ultimate bestaat niet meer, alle Ultimate features komen nu dus in Enterprise terecht.
Dit halveert de kosten voor Ultimate features.

En de prijs voor Professional is ook met MSDN erbij, net als bij Enterprise.

[GMavak]

Als het goed is heb je de UnityVS extension niet meer nodig. Dat is het enigste wat veranderd.

[LOTG]

Niet bepaald, zelfs de site van Visual Studio verwijst naar UnityVS.

Ik was inderdaad wel blij geweest als het wat beter was geworden.

Het grootste gemist vind ik nog altijd dat er geen edit and continue is. Vooral wanneer Unity niet in Play state staat. Nu moet je iedere keer weer attach/unattach doen om even snel wat te veranderen.

[SG]

Dus ipv XNA heb je nu Unity3D ingebakken om met C# games te maken. En heb je zwaardere Eisen Unreal in VS om het C++ te doen? Heel interressant dit.

[LOTG]

Er zit helemaal niets ingebakken, je kunt extensions downloaden om het te laten samen werken met de engines. Daarnaast moet je nog steeds Unity of Unreal Engine installeren. Visual Studio fungeert dan eigenlijk min of meer als IDE voor het scripten, en voor het debuggen van code.

Unity gebruikt bijvoorbeeld Mono, en levert zelf dan ook Monodevelop mee. Het gaat dan dus ook geen gebruik maken van de nieuwe C# features in C# 6.

Vandaar dus ook mijn verbazing dat het nogal groot aan de klok gehangen word terwijl er eigenlijk niets veranderd is ten opzichte van 2013.

[Jogai]

Klopt, lijkt een verwijzing naar http://blogs.msdn.com/b/s...l-engine-and-cocos2d.aspx maar dat was ook al voor 2013.

[bjamri]

Als Microsofts filisofie werkelijk betekent dat men van Visual Studio een "universeel platform" wil maken, hoe lang duurt het dan nog voordat het zonder commerciële plugins PHP ondersteunt?

De beste IDE voor PHP die ik tot nu toe heb gevonden is NetBeans (mening), nadat ik ook gewerkt heb met (o.a.) Eclipse en CodeLobster. Toch is het een flinke stap terug als ik overdag VS gebruik voor C# en het 's avonds privé met NetBeans moet doen.

[BCage]

De beste IDE voor PHP is PHPStorm. Er is al bijna geen discussie meer over mogelijk. Ik kom ook van Netbeans af, maar ik zou echt nooit meer terug willen. Fantastische IDE, op gelijk niveau met Visual Studio. Ik zie het onder freelancers en gedetacheerde ontwikkelaars zo langzamerhand een industrie standaard worden.

[Reactie gewijzigd door BCage op 23 juli 2024 03:38]

[bjamri]

@BCage: Door Netbeans te zetten tegenover Visual Studio zonder commercielële plugins verwachtte ik dat het duidelijk was dat ik ook een gratis IDE voor PHP zoek. Dan valt PHPStorm helaas af.
Als ik toch geld wil neerleggen waarom zou ik dan niet kiezen voor het voordeliger PHP Tools for Visual Studio?