dotnet new

by Rok Bermež 15. June 2016 13:12
Ena izmed opcij novega dotnet orodja za orodno vrstico je tudi 'new' in nam omogoča inicializirati nov .Net projekt. V osnovi nam ponuja dodatne –t kot tip in –l kot jezik dodatne možnosti ter seveda privzeto prazno, ki bo generirala 'Hello World' konzolno aplikacijo, ki jo lahko odpremo s katerimkoli urejevalnikom besedil ali pa kar takoj prevedemo in poženemo: D:\Pika>dotnet new Created new C# project in D:\Pika. D:\Pika>dotnet restore log : Restoring packages for D:\Pika\project.json... log : Writing lock file to disk. Path: D:\Pika\project.lock.json log : D:\Pika\project.json log : Restore completed in 1612ms. D:\Pika>dotnet run Project Pika (.NETCoreApp,Version=v1.0) will be compiled because expected outputs are missing Compiling Pika for .NETCoreApp,Version=v1.0 Compilation succeeded. 0 Warning(s) 0 Error(s) Time elapsed 00:00:01.3401987 Hello World! Kot smo že omenili, lahko z -l zamenjamo jezik in z "dotnet new -l F#" naredimo namesto C# raje F# konzolno aplikacijo: D:\Pika>dotnet new -l F# Created new F# project in D:\Pika. D:\Pika>type Program.fs ´╗┐// Learn more about F# at http://fsharp.org open System [<EntryPoint>] let main argv = printfn "Hello World!" printfn "%A" argv 0 // return an integer exit code D:\Pika> Z –t izbiramo tip želenega projekta, tako na primer "dotnet new -t lib" hitro naredi novo knjižnico za enim Class1 razredom in prazno Empty metodo. Samo po sebi ne najbolj koristno, vendar vseeno v »dobro je vedeti« kategoriji. Prav tako lahko z "dotnet new -t xunittest" naredimo nov testni projekt, ki pa ga tokrat po "dotnet restore" pokličemo z "dotnet test": D:\Pika>dotnet new -t xunittest Created new C# project in D:\Pika. D:\Pika>dotnet restore log : Restoring packages for D:\Pika\project.json... warn : Dependency specified was dotnet-test-xunit (>= 1.0.0-rc2-192208-24) but ended up with dotnet-test-xunit 1.0.0-rc2-build10015. log : Writing lock file to disk. Path: D:\Pika\project.lock.json log : D:\Pika\project.json log : Restore completed in 2122ms. D:\Pika>dotnet test Project Pika (.NETCoreApp,Version=v1.0) will be compiled because expected outputs are missing Compiling Pika for .NETCoreApp,Version=v1.0 D:\Pika\project.json(9,46): warning NU1007: Dependency specified was dotnet-test-xunit >= 1.0.0-rc2-192208-24 but ended up with dotnet-test-xunit 1.0.0-rc2-build10015. Compilation succeeded. 1 Warning(s) 0 Error(s) Time elapsed 00:00:01.4732457 xUnit.net .NET CLI test runner (64-bit win10-x64) Discovering: Pika Discovered: Pika Starting: Pika Finished: Pika === TEST EXECUTION SUMMARY === Pika Total: 1, Errors: 0, Failed: 0, Skipped: 0, Time: 0,184s SUMMARY: Total: 1 targets, Passed: 1, Failed: 0. Imamo tudi ASP.NET Core Hello World, do katerega pridemo s pomočjo ukaza "dotnet new -t Web.", ki nam naredi lep in enostaven začetni primer ASP.NET Core aplikacije, s primeri uporabe tehnologij kot so bower, gulp in npm. Alternativno lahko ustvarjamo ASP.NET Core projekte tudi s pomočjo precej močnejšega Yeoman Asp.Net generatorja: Vsi ti generatorji delujejo na Windows , Mac in Linux operacijskih sistemih, tako da bomo kmalu lahko 'vse' kar nam ponudi Visual studio v "File | New Project " menuju, lahko naredili preko orodne vrstice, tudi v konkurenčnih svetovih.

Tags:

.Net | c# | mvc | Web | Visual Studio

Oracle z oblaka

by Rok Bermež 27. March 2012 12:41
Oracle z oblaka Včasih dobi kdo fiksno idejo, da integracija med aplikacijami pomeni pisanje ene aplikacije direktno v podatkovno bazo druge. V primeru, da naša aplikacije teče v Microsoftovem oblaku, druga pa uporablja Oracle podatkovno bazo skrito na neki skriti interni mreži, pridemo do zanimivega problema. Če ga razdelimo na dva dela, vidimo da moramo prvo nekako fizično povezati naše oblačne VM na katerih teče naša aplikacija z strežnikom na katerem se nahaja Oracle, brez da bi ga pri tem izpostavili celotnemu internetu. Nato, pa bo treba še našo aplikacijo prepričati oziroma mogoče bolje primerno rečeno VM na katerem teče, da se bo dejansko znala pogovarjat z #«!#!. Za rešitev prvega problema lahko uporabimo mehanizem, ki sliši na ime Windows Azure Connect , in nam omogoča 'point to point' VPN povezavo med računalniki, ne glede na to na kakšnih mrežah in za kakšnimi požarnimi se nahajajo, seveda če imajo ti vsaj internetno povezavo. Tega se lotimo tako, da na Windows Azure management portalu prisurfamo na 'Virtual Network' sekcijo, izberemo naročnino ter zahtevamo aktivacijski žeton in s tem vklopimo to storitev za našo naročnino. Nato v naših oblačnih vlogah vklopimo Connect modul, tako da v ServiceDefiition.csdef dodamo: Ter mu v csconfig datoteki nastavimo specifično naš aktivacijski žeton: Za dostop do lokalnih virov, pa morama na vse računalnike do katerih bi radi dostopali namestiti Windows Azure Connect Endpoint programsko opremo, ki jo dobimo na naslovu (pri čemer moramo obvezno uporabiti Internet Explorer brskalnik): https://waconnecttokenpage.cloudapp.net/Default.aspx?token=moj_žeton_guid. Po namestitvi, se bo nekaj sekund kasneje računalnik pojavil kot aktiviran na management portalu. Preostane nam samo še konfiguracija naše virtualne mrežne topologije, kar naredimo tako da ustvarimo EndPoint skupino ter nastavimo primerna pravila. Pri čemer lahko obkljukajo 'Interconnected' opcijo in s tem poskrbimo, da se bodo tudi lokalni EndPointi videli med seboj ter bodo tako dosegljivi tudi drug za drugega in ne zgolj z oblačnih virov. Privzeto vlog v oblaku ne moremo pingati ker imajo vklopljen požarni zid, ki pa mu lahko z enostavno zagonsko nalogo (Startup task) dodamo novo pravilo in tako omogočimo tudi ping v oblak. Prvi problem je tako rešen in se lahko posvetimo drugemu. Povezava na Oracle podatkovno bazo iz .NET kode z uporabo Oracle.DataAccess knjižnice ni problematična dokler imamo na sistemu nameščene Oraclove ODAC komponente, ki pa jih privzeto na VMjih v Windows Azure Compute storitvah ni. Za njihovo namestitev bomo morali tako poskrbeti sami in sicer mora biti zadeva avtomatsko nameščena ob vsakem novem deploymentu. Prvi korak je iz oraclovega spletnega mesta poberemo zahtevane komponente; trenutno ODAC 11.2 Release 4 (11.2.0.3.0) with Xcopy Deployment, ki pa morajo biti 64 bitne in jih ni malo (okoli 60MB v kompresirani obliki). Tako bi v primeru, da bi jih deployali z našo aplikacijo, kar precej povečalo čas deploymenta. Zato jih je precej bolj smiselno odložiti v Azure Storage in poskrbeti da se v okviru zagonske naloge (Startup taska) naložijo na VMjev sistem, odpakirajo ter namestijo. PowerShell skripta, ki bo vse te naloge opravila bo izgledala nekako tako: Preden pa jo bomo v okviru zagonske naloge poklicali pa moramo poskrbeti, da bo poklicana zgolj v pravem in ne tudi v emuliranem okolju ter nastaviti politiko izvajanja PowerShell skript. Preostane nam zgolj registracija zagonske naloge v ServiceDefinition.csdef datoteki. Pozorni moramo biti, da imajo vse potrebne datoteke (*.cmd, *.ps1) 'Copy to Output Directory' opcijo nastavljeno na ' Copy always', nato pa lahko brez skrbi glede nadaljnjih popravkov in deplyomentov, na oblak namestimo našo aplikacijo, ki je sposobna komunicirati z 'on premises' Oracle podatkovno bazo.

Tags:

.Net | Azure | Visual Studio

Dev Web Server for Azure Web Roles

by Rok Bermež 27. January 2011 13:17
Windows Azure uses 64 bit architecture so all dlls deployed to it must also be 64 bit. This poses significat development problem since 'Visual Studio Development Server'  and IIS Express run in 32 bit process. You can always use complete IIS, but it would be better if there was something more lightweight. It turns out there is. There is a nice project on codeplex called "CassiniDev - Cassini 3.5/4.0 Developers Edition" available here. Its binaries are also 32 bit so be sure to get the source and change Build platform target to either 'Any CPU' or 'x64'    and rebuild solution. After that just replace contents of 'C:\Program Files (x86)\Common Files\microsoft shared\DevServer\10.0' folder with your new freshly build 64 bit capable dev server  

Tags:

Azure | IIS | Visual Studio | Web

... azure looks back at you

by Rok Bermež 8. January 2011 14:22
It’s been a month since Azure SKD 1.3 has been released with a lot of new features. Let’s take a look at the ability to user Remote Desktop Connection to your roles first.In order to enable this feature we must configure our deployments to support it. The easiest way to do so is to right click on cloud service project in visual studio and choose deploys. There you can click on 'Configure Remote Desktop connections'. Here you can enable RDP connections for all roles and you must set the required security credentials. So let’s create a security certificate first. Then we set user credentials for our RDP account and set its expiration date. After that, we export the security certificate so we can upload it to the cloud (you can click on view to open it directly). We also export private key And then we upload exported file through the Windows Azure Management portal to our chosen hosted service. If we take a closer look at what our Visual Studio Wizard did, we can open ServiceDefinition.csdef and ServiceConfiguration.cscfg and see xml additions. Now we can deploy our solution anyway we like. Once the deployment is complete and our role is in 'ready' state we can download or open .rdp file through Azure Management portal. Now we can finally connect to our instance ... and azure looks back at you NOTE: Changes made to instance will NOT be persisted. This was meant for easier debugging. If you want to take full advantage of IIS configuration you will need to use ‘Full IIS’ feature, which will be covered in my next post.

Tags:

.Net | Azure | IIS | Visual Studio

Bulletproof Cross-Browser CSS Techniques

by Rok Bermež 13. October 2010 09:44
I've written up a summary of all tehniques and tricks for cross-browser CSS coding I've learned over [More]

Tags:

ASP.NET | Design | Development | Visual Studio | Web

Calendar

<<  May 2017  >>
MonTueWedThuFriSatSun
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar

Page List

Month List