mboost-dp1
No Thumbnail
Yep, det er da godt de har fået lavet en version. Men af en eller anden grund mindes jeg at det var i samarbejde med Novell og ikke Mono? men det er måske bare mig der husker forkert :-/
Men sådan til selve projektet, tror jeg nu stadigt de for svært ved at slå adobe som har et rigtigt godt produkt, som mange benytte sig af :D
Men sådan til selve projektet, tror jeg nu stadigt de for svært ved at slå adobe som har et rigtigt godt produkt, som mange benytte sig af :D
Monolight er blevet specielt godt, for Microsoft faktisk indså at det var nødvendig at gøre visse dele af XAML specifikationen open-source.
Og derfor har de også støttet Monolight.
Da Adobe gjorde dele af flash frit, så kunne Microsoft simplethen ikke omgå at gøre dele af XAML frit også.
Længe leve gruppepres :p
Og derfor har de også støttet Monolight.
Da Adobe gjorde dele af flash frit, så kunne Microsoft simplethen ikke omgå at gøre dele af XAML frit også.
Længe leve gruppepres :p
#2 - http://www.monodevelop.com/MonoDevelopWin32
Sponsored by Novell, the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications.
3 skrev:Men af en eller anden grund mindes jeg at det var i samarbejde med Novell og ikke Mono?
Sponsored by Novell, the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications.
#6: Jep ved godt den eksisterer :) Men den er da et helvede at installere. Sådan noget skal virke straight-out-of-the-box uden for mange dikkedarer.
.. og så er den ret eksperimentiel .. Men Novell/Ximian har lovet en rigtig Windows-version skulle komme på et tidspunkt. Bl.a. derfor kan man ikke kompile op mod Mono i den seneste "konkurrerende" IDE SharpDevelop version 3.
.. og så er den ret eksperimentiel .. Men Novell/Ximian har lovet en rigtig Windows-version skulle komme på et tidspunkt. Bl.a. derfor kan man ikke kompile op mod Mono i den seneste "konkurrerende" IDE SharpDevelop version 3.
Nu har jeg ikke så meget indsigt i Moonlight, men skal det være rigtig godt skal det vel være muligt at udvikle i VS.NET og så bare afvikle den applikation under Linux via Moonlight.
Hvis man skal til at compile/udvikle specielt til Moonlight, går noget af ideen vel lidt fløjten.
Hvis man skal til at compile/udvikle specielt til Moonlight, går noget af ideen vel lidt fløjten.
#2
Monodevelop er vist nok portet til windows...
Men hvorfor skulle man ønske at starte sin Virtual Machine op fr at udvikle mono under windows???
Man kan godt kører Linux på sin hardware, det er jo ikke ligesom windows bør køre i virtualle omgivelser...
PS. monodevelop er ikke helt så stærk og stabil som f.eks. sharpdevelop... Men MonoDevelop har nogle ret gode deployment muligheder...
#8
Det kan du også... i begrænset omfang... det er som når du udvikler hjemmesider, den skal altid testes i både Firefox og Internet Explorer (hvis man da gider understøtte sidst nævnte).
Kompatibiliteten mellem Mono og .Net er dog meget bedre end den mellem IE og FF...
Monodevelop er vist nok portet til windows...
Men hvorfor skulle man ønske at starte sin Virtual Machine op fr at udvikle mono under windows???
Man kan godt kører Linux på sin hardware, det er jo ikke ligesom windows bør køre i virtualle omgivelser...
PS. monodevelop er ikke helt så stærk og stabil som f.eks. sharpdevelop... Men MonoDevelop har nogle ret gode deployment muligheder...
#8
Det kan du også... i begrænset omfang... det er som når du udvikler hjemmesider, den skal altid testes i både Firefox og Internet Explorer (hvis man da gider understøtte sidst nævnte).
Kompatibiliteten mellem Mono og .Net er dog meget bedre end den mellem IE og FF...
Update: I apologize for the confussion; This is not Moonlight 1.0, this is the first source code release that we are making of Moonlight for interested contributors and developers. This release is not even a Beta release...- http://tirania.org/blog/archive/2008/May-13-1.html
#11
Det ved jeg - bruger selv Visual Studio 2005, og regner med regner med at opgradere til 2008 inden længe.. Men derfor er jeg stadig interesseret i at se MonoDevelop på Windows fordi jeg mener, det er godt at der er lidt konkurrence på området.
Visual Studio er skræmmende godt, men det er også ubehageligt lukket. F.eks er det først i VS2008 at der er implementeret så du kan compile mod gamle udgaver af .NET (med mindre man har lyst til at jonglere med på commandline'n med MSBuild/MSBee), en ting som SharpDevelop og MonoDevelop har kunnet længe.
Det ved jeg - bruger selv Visual Studio 2005, og regner med regner med at opgradere til 2008 inden længe.. Men derfor er jeg stadig interesseret i at se MonoDevelop på Windows fordi jeg mener, det er godt at der er lidt konkurrence på området.
Visual Studio er skræmmende godt, men det er også ubehageligt lukket. F.eks er det først i VS2008 at der er implementeret så du kan compile mod gamle udgaver af .NET (med mindre man har lyst til at jonglere med på commandline'n med MSBuild/MSBee), en ting som SharpDevelop og MonoDevelop har kunnet længe.
18 skrev:#17
Omstændigt ?
Det synes jeg nu ikke tværtimod, gør det en hel del ting meget nemmere.
Hehe, der bliver vi vist aldrig enige ;-)
18 skrev:#17
Men ja det er nice man kan det nu, men ærligt talt er det ikke en feature jeg har manglet overhovedet. Jeg har kodet .net siden 1.1. Nu laver jeg alt i 3.5
Det gad jeg også godt jeg kunne, desværre har jeg nogle installationer rundt omkring som jeg ikke bare kan opdatere uden videre, da nogle webhoteludbydere ikke har opdateret til 3.5 endnu.
9 skrev:#2
Monodevelop er vist nok portet til windows...
Se mit indlæg #7
9 skrev:
Men hvorfor skulle man ønske at starte sin Virtual Machine op fr at udvikle mono under windows???
Man kan godt kører Linux på sin hardware, det er jo ikke ligesom windows bør køre i virtualle omgivelser...
Ikke helt forstået. Både Mono og Moonlight bryster sig af at være platformuafhængigt, bør der så ikke også være de rette værktøjer på flere platforme, som kan køre native under det OS man bruger? Jeg synes det er lidt uhyggeligt at Visual Studio er så godt, at der praktisk talt ikke er nogen konkurrence på det punkt, så alle nye tiltag er velkomne i mine øjne. Selvom det vil givetvis vil vare længe inden Silverlight for alvor får tag i folk, så er det også på tide at Adobe Flash får noget konkurrence
Ifølge et bekendt som er programmør, så skulle Silverlight være rigtig fedt at arbejde med... Som bruger har jeg ikke haft problemer med det heller.
#16 og 18
Køre to forskellige versioner af VS evt. endda på forskellige systemer for at builde med to forskellige versioner af .NET er da ikke bare lidt men meget klodset.
Og det kan godt være at du ikke har behov for at supportere ældre versioner, men det er der mange som har. "Hvordan får jeg VS 2005 til at bygge mod .NET 1.1" er st spørgsmål som bliver stillet meget ofte.
Køre to forskellige versioner af VS evt. endda på forskellige systemer for at builde med to forskellige versioner af .NET er da ikke bare lidt men meget klodset.
Og det kan godt være at du ikke har behov for at supportere ældre versioner, men det er der mange som har. "Hvordan får jeg VS 2005 til at bygge mod .NET 1.1" er st spørgsmål som bliver stillet meget ofte.
#23
Har du nogensinde hørt om et program fra Microsoft der hedder Virtual PC ?
Med dette smarte program kan du havde x antal OS'er, VS'ere MsSQL'ere, IIS'ere i alle de kombinationer du ønsker, uden at skulle bruge flere maskiner.
Det er faktisk ret smart, tag og prøv det. men det kræver selvfølgelig du tænker lidt ud af boksen, og ikke bare ser problemer i alt.
Skulle jeg komme i den situation jeg skal lave noget i 1.1, starter jeg bare en virtuel maskine med VS 2003, og problemet er løst, dejligt nemt. (ihvertefalde det med at builde til 1.1, selve udviklingsopgaven er en helt anden sag :-)
Har du nogensinde hørt om et program fra Microsoft der hedder Virtual PC ?
Med dette smarte program kan du havde x antal OS'er, VS'ere MsSQL'ere, IIS'ere i alle de kombinationer du ønsker, uden at skulle bruge flere maskiner.
Det er faktisk ret smart, tag og prøv det. men det kræver selvfølgelig du tænker lidt ud af boksen, og ikke bare ser problemer i alt.
Skulle jeg komme i den situation jeg skal lave noget i 1.1, starter jeg bare en virtuel maskine med VS 2003, og problemet er løst, dejligt nemt. (ihvertefalde det med at builde til 1.1, selve udviklingsopgaven er en helt anden sag :-)
#24
Jeg bruger ikke Virtual PC men Virtual Server og VMWare.
Og du kan da ikke seriøst påstå at en virtuel maskine med en anden version af VS er en smart løsning på at kunne builde til forskellige versioner af .NET.
Selv ikke MS mener det - siden de har lyttet til kritikken og indført muligheden for at builde til 2.0+ i VS 2008.
Jeg bruger ikke Virtual PC men Virtual Server og VMWare.
Og du kan da ikke seriøst påstå at en virtuel maskine med en anden version af VS er en smart løsning på at kunne builde til forskellige versioner af .NET.
Selv ikke MS mener det - siden de har lyttet til kritikken og indført muligheden for at builde til 2.0+ i VS 2008.
Angående compile til gamle udgaver af .NET, så har jeg nu aldrig haft problemer med at køre forskellige VS installationer side om side på samme maskine.
På min workstation har jeg både VS 2003, VS 2005 og VS 2008 installeret uden at det giver problemer.
Angående multitarget så er det spørgsmålet om det er noget vi vil se videreført i næste VS version - den største årsag til at de tilbyder det i VS 2008 er at .NET 3.0 og .NET 3.5 primært er library udvidelser, CLR'en er stadig en 2.0'er.
Derudover skal man have for øje at selvom man compiler op imod 2.0 i VS 2008, så er det ikke ensbetydende med at programmet kan afvikles på en maskine med en normal 2.0 installation. Den 2.0'er man compiler op imod i VS 2008 er reelt en .Net 2.0 SP1, som indeholder udvidelser til bl.a. understøttelse af C# 3.0 features (Linq, og lign.). Skal det lykkedes skal man altså sørge for at man ikke gør brug af det Microsoft betegner "red bits" i 2.0 SP1.
Man kan så få en udvidelse til FXCop som kan tjekke op på om man anvender SP1 kald, men det er også en smule bøvlet.
Vil man sikre bagudkompatibilitet med gamle .NET 2.0 installationer er VS 2005 altså stadig det bedste bud.
Hvad der iøvrigt gør det ekstra sjovt er at den nemmeste måde at opgradere en .NET 2.0 klient til .NET 2.0 SP1, er ved at installere .NET 3.5 frameworket - så er man ikke opmærksom på det med red bits, så er der faktisk ikke meget hentet i at sætte target til 2.0 istedetfor 3.5 i VS 2008.
På min workstation har jeg både VS 2003, VS 2005 og VS 2008 installeret uden at det giver problemer.
Angående multitarget så er det spørgsmålet om det er noget vi vil se videreført i næste VS version - den største årsag til at de tilbyder det i VS 2008 er at .NET 3.0 og .NET 3.5 primært er library udvidelser, CLR'en er stadig en 2.0'er.
Derudover skal man have for øje at selvom man compiler op imod 2.0 i VS 2008, så er det ikke ensbetydende med at programmet kan afvikles på en maskine med en normal 2.0 installation. Den 2.0'er man compiler op imod i VS 2008 er reelt en .Net 2.0 SP1, som indeholder udvidelser til bl.a. understøttelse af C# 3.0 features (Linq, og lign.). Skal det lykkedes skal man altså sørge for at man ikke gør brug af det Microsoft betegner "red bits" i 2.0 SP1.
Man kan så få en udvidelse til FXCop som kan tjekke op på om man anvender SP1 kald, men det er også en smule bøvlet.
Vil man sikre bagudkompatibilitet med gamle .NET 2.0 installationer er VS 2005 altså stadig det bedste bud.
Hvad der iøvrigt gør det ekstra sjovt er at den nemmeste måde at opgradere en .NET 2.0 klient til .NET 2.0 SP1, er ved at installere .NET 3.5 frameworket - så er man ikke opmærksom på det med red bits, så er der faktisk ikke meget hentet i at sætte target til 2.0 istedetfor 3.5 i VS 2008.
#25
Fremfor at Microsoft i al evighed, skal sikre de kan builde til æld gamle versioner af deres framework, jo absolut kan jeg det.
Men som #26 skriver, og som du sikkert ved, hvis du bre kender lidt til .net udvikling, så kan de også sagtens være på maskinen side om side uden problemer.
Når du skal lappe et gammel .net 1.1 program du har lavet, ja så har du jo VS2003, og derfor kan den sagtens være på maskinen.
Du vil vist bare se ulemper i alt.
Og du kan da ikke seriøst påstå at en virtuel maskine med en anden version af VS er en smart løsning på at kunne builde til forskellige versioner af .NET.
Fremfor at Microsoft i al evighed, skal sikre de kan builde til æld gamle versioner af deres framework, jo absolut kan jeg det.
Men som #26 skriver, og som du sikkert ved, hvis du bre kender lidt til .net udvikling, så kan de også sagtens være på maskinen side om side uden problemer.
Når du skal lappe et gammel .net 1.1 program du har lavet, ja så har du jo VS2003, og derfor kan den sagtens være på maskinen.
Du vil vist bare se ulemper i alt.
26 skrev:
Angående multitarget så er det spørgsmålet om det er noget vi vil se videreført i næste VS version - den største årsag til at de tilbyder det i VS 2008 er at .NET 3.0 og .NET 3.5 primært er library udvidelser, CLR'en er stadig en 2.0'er.
Det tror jeg bestemt - groft set er den eneste hindring der er i f.eks VS2005 for at du ikke kan compile op mod .NET 3.5 er at stien til MSBuild i din projectsfil er hardcoded til at pege på C:\Windows\Microsoft.NET\v2.0.20575\msbuild.exe og så at den peger på v2.0-udgaven af mscorlib.dll + nogle flere. Men det kan man jo bede den om at lade være med og så selv manuelt lave sine referencer ;)
#27
Med en fornuftig adskillelse af IDE og compiler så bør det ikke vær noget problem.
Alle de gængse Java IDE'er kan finde ud af det, Borland C++BuilderX kan finde ud af det. NAnt kan gør edet for .NET.
Jeg er sikker på at MS kan finde ud af det også.
Og det er ligesom hele ideen med en IDE at lave det nemt for udviklerne.
Og som tidligere nævnt så virker det også som om MS efter 6 år har fanget pointen.
Hvis du læser mine indlæg tilpas grundigt vil du se at jeg er klar over det.
Men derfor er det jo stadig:
multitarget build - den rigtige måde
flere versioner af VS på samme system - ekstra arbejde
flere versioner af VS på forskellige systemer - 2 x ekstra arbejde
Fremfor at Microsoft i al evighed, skal sikre de kan builde til æld gamle versioner af deres framework, jo absolut kan jeg det.
Med en fornuftig adskillelse af IDE og compiler så bør det ikke vær noget problem.
Alle de gængse Java IDE'er kan finde ud af det, Borland C++BuilderX kan finde ud af det. NAnt kan gør edet for .NET.
Jeg er sikker på at MS kan finde ud af det også.
Og det er ligesom hele ideen med en IDE at lave det nemt for udviklerne.
Og som tidligere nævnt så virker det også som om MS efter 6 år har fanget pointen.
Men som #26 skriver, og som du sikkert ved, hvis du bre kender lidt til .net udvikling, så kan de også sagtens være på maskinen side om side uden problemer.
Hvis du læser mine indlæg tilpas grundigt vil du se at jeg er klar over det.
Men derfor er det jo stadig:
multitarget build - den rigtige måde
flere versioner af VS på samme system - ekstra arbejde
flere versioner af VS på forskellige systemer - 2 x ekstra arbejde
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund