System.Web has been removed in ASP.NET 5, so how do I find the new places? - asp.net-core

So I jsut managed to deploya very basic MVC site on Ubuntu, behind nginx served by kestrel. Fantastic.
Now I just wanted to do a simple thing like show the visitors reported IP address, just for fun. You know, I want it to lead up to SQL/MySql get the whole feature set going on within Ubuntu.
But System.Web was removed from aspnet50 and broken down and you cannot just access System.Web.HttpContext... or Reaquest.UserHostAddress()
I can see #Request but I doesnt have all the properties I would be expecting.
How do I find... or am I supposed to find which dependency to add which contains that feature or any other feature I might be looking for from the full .NET 4.5 MVC?

To quickly find out which package might contain a type you're looking for, check out the totally unofficial Reverse Package Search. Just type in something like IPAddress and you'll get a list of packages that are good hints.
It's of course not 100% reliable, but it's better than guessing.

If you have JetBrains' ReSharper, it also provides context actions to find a namespace or a type on NuGet:
http://www.jetbrains.com/resharper/help/Finding_Exploring_and_Installing_NuGet_Packages.html

Related

what is swagger exactly ? And why doesn't the online editor run requests?

I've spent the last few days trying to understand if I should use api blueprint, RAML or swagger.
It looks like swagger has the biggest community but the closer I look the more I feel that it greatly lacks in documentation (I was forced to look at the code many times to try and integrate it with my current project), many github issues and stackoverflow questions are unanswered.
Is it possible that I am missing something here?
All I want is a tool to help me write the API documentation and test the endpoints.
Why must swagger become part of the server logic?? If I create swagger files in the editor and then serve them to the UI directly it breaks..
As far as I can tell it even makes the server slightly slower and forces the existence of many clumsily maintained integrations :p What am I missing here?
We're trying to work a lot on improving the documentation of Swagger. It's a bit more difficult when many of the projects are community-driven and not managed by a single organization.
We actually try to reply to issues on github quickly (we don't always succeed) and we have our own google group for general questions so we follow stackoverflow somewhat less.
The editor you mention is a new tool as part of the work on Swagger 2.0 and it's not final yet. As such, it still have a few bugs and missing features. The UI is also in the process of being adapted to Swagger 2.0 and the same limitations apply to it.
You most certainly don't have to integrate it with your server and you can expose the documentation statically. The advantage of integrating it with the server is that it's easier to maintain if the API changes.
You can try RAML + ramlev + Abao
The steps should be
Write API Spec in RAML with your fav editor, ie. Atom, vim
Validate your RAML with ramlev
Implement the server logic according API Spec
Validate server logic with Abao

does magnolia implement struts? and If i have something with struts its easy to integrate?

I am very new in magnolia and I still have some difficults getting the idea to develop components, but my problem is that after read the docs offered in the site (I wonder if there are other kind of docs, as only for developers) I still dont get if they use Struts or not, at first I thought so, but I am not sure at all, could somebody tell me this? Just to know be clear.
Thanks
I see nothing resembling a Struts 1 or Struts 2 signature anywhere in any of the Magnolia artifacts. I'm not sure what made you think it used Struts, and downloading their CE it was a simple matter of looking at the deployed jars to see that it didn't.
I also checked a couple of the Magnolia libraries to see if there were shaded versions and I saw nothing of note. While I didn't spend much time on this (~five minutes) there's nothing obviously Struts-ish.

Where can I find up-to-date documentation about the WCF Web API?

I've been strugling with WCF to do REST the way I want it to work. And apparently so has quite a few others. I've heard about the WCF Web Api project, but wrongly dismissed it without looking too closely at it. Sadly, now that I'm looking at it I find that the documentation is rather outdated. Like, this blog post has some nice information, but classes have changed, parameters have changed, in short, design has changed.
So I've been using an old example of how to plug in Json.NET (newtonsoft) as my serializier, only to realize that after I had it working, it wouldn't work for my IErrorHandler. Further I had a problem with how to Deserialize a string from the uri template to an operation Type parameter.
It appears however that I should be able to solve these two problems (and presumably many others that I haven't stumbled over yet) by using the media formatter extension point and what's referred to as Processor<..>s in outdated documentation, which is now HttpOperationHandler<..>s unless I've missunderstood.
My problem is rather basic, I can't figure out how to correctly configure my IIS-hosted app to use my operation handler, assuming I've implemented it correctly. Since it feels rather dumb to ask for instructions on such a basic thing, I'll rather ask where I can find some documentation on how to do this sort of thing? (Explanations are welcome of course.)
I'm not after seing which classes exist, or what their methods are named with what parameters. I can see all that in my object browser. I need documentation for the overall design, and/or examples implicitly describing things like:
How do the different classes in the API fit together?
How can I configure from web.config?
Must I rather do a custom HttpServiceHostFactory?
What and how are you meant to use the framework?
How should I extend to reach what sort of goals?
How should I configure to place the extensions in effect?
From the lack of answers I assume the documentation quite simply isn't ready.
I was looking for it on the codeplex site under the Documentation tab, and found outdated stuff.
However, after familiarizing myself a bit with Codeplex I found out that the good stuff was in this Discussion section. Searching a bit in there helped a lot to be honest.
Concerning config-file configuration, I didn't find anything, so I'm assuming this will be added as the last thing before official release. Meaning I'll use the HttpConfiguration in a custom HttpServiceHostFactory for now.
The trick about the HttpOperationHandlers was twofold: Firstly I was throwing an exception in my operation and hadn't implemented a global HttpErrorHandler yet. (Doh!) Secondly I didn't know that the parameter name of HttpOperationHandler<..>.OnHandle had to match the name of the operation parameter.

Best practice for a Sitecore project

I am rather new to Sitecore and would like to know a bit more about the regular approach to a new project. I'm therefore willing to listen and try out some of the experienced Sitecore developers solutions. I have alot of questions, i won't ask them all. I am just very curious to the approach other people have.
What would be the best approach to start a Sitecore project?
How would you set your project up?
What will be your approach looking at the recycling of code in future projects?
In short: What experiences do YOU have (if you have worked with or are working on Sitecore projects) and how would you recommend other people to work with Sitecore.
Right now we are busy on building Sitecore blocks that we can just recycle in other projects but i know for sure there are 1001 handy tips and tricks out there. I hope we have some Sitecore pro's # stackoverflow that could help a bit.
Here is some general setup info, based on how we do things.
Subversion
This is not Sitecore specific but we set up our repository like this
branches - This is used for working on big updates to the site that may take a while. Say for example I wanted to update how all of the sidebars on the site worked, and this was going to take a few weeks to complete. What we do is create a new branch, and set up another sitecore instance for this dev branch and do what we need to do. When it is complete we merge it back into the trunk for testing and deployment.
tags - This is used for keeping a copy of code that will never be merged back into the trunk (that is the difference between this and branches), so for example when we deploy an update to a site we can create a tag of said code so we can go back to it if necessary.
trunk - The active code, anything checked in here should always be deployable.
The Trunk
This is where we are actively developing/fixing bugs, depending on which part of the project that we are on. We set it up something like this (as an example the project is called TheProject)
We keep our solution file at the root of this folder, this will reference the various libraries in the src folder as well as the web project in the website folder.
docs - A place to put documentation about the site. I strongly suggest that as you complete features/sections you write up a little guide about any special knowledge needed for it to work. So say I am working on a featured content box on a landing page. This box will automatically pull some content unless it is explicitly overridden. What I do when I complete something like this is I write a guide for the customer, using a lot of screenshots. I send the guide to the customer as well as put it in the docs folder. This both helps the customer train their staff, as well as helps new developers come up to speed with how things are done.
lib - This is where we keep any DLLs we are going to need to reference in our projects.
test - A place to put unit tests.
src - This is where we keep our project specific library code. So in here we would have a folder called TheProject.Library, and in there would be the visual studio project for said
web/Website - This is where we have Sitecore installed and is the root of the site. In here we have a project called something along the lines of TheProject.Web. In the project we add all of the general stuff like the web.config/layouts folder and so on.
General Sitecore Code Library
One the best things you can do is from the start setup a general Sitecore library that can be added onto over time. Then when you write any code for a project that is not only applicable to the project, you can add it there. It may seem obvious, but this will really help in the long term. You will end up with much more solid code, see link text .
So when we are done with all this we have something like this as a solution/project structure
TheProject (The solution)
TheProject.Library
TheProject.Web
MyCompany.SitecoreLibrary (our general sitecore library)
Tools
This is another general thing, but I find it can really help speed up Sitecore development. If you find yourself doing something over and over in Sitecore, using API write a tool to do it for you. This not only helps with solving whatever problem you are tackling, but also helps to get you more familiar with the API.
Resharper
This is more of a general .NET development suggestion, use Resharper(http://www.jetbrains.com/resharper/index.html). I am sort of a a Resharper fan boy, it makes so many things with development easier and quicker. In my mind the biggest advantage though is how easy it makes refactoring code, which is really important to do over time to keep things clean and understandable.
I hope some of this helps.
Gabe
This is, as you said, quite a big question. Here are some of my thoughts:
Developing Environment
First of all when I start a new project I install Sitecore on my developing environment and I make sure everything works. Either during installation or after I place the databases on a separate SQL-server and change the connectionstring accordingly.
I open up Visual Studio and create a solution and include the files needed. I create some kind of HelloWorld rendering and try building the solution so that I can verify that everything is working as it should.
When everything is up and running I create a zip-file of the whole solution, including the data-folder. Now it is time to add this to some kind of version control system, in my case Subversion.
I add the zip-file to subversion and also add all files that I think will be changed during the project, usually I tell subversion to ignore the sitecore folder, this speeds up performance drastically when checking in files.
After I perform a commit-action the other team members of my project can check out the code and start developing (after unzipping the zip-file, off-course)
We all work towards the same database although this goes against Sitecore recommendations, we havent had any problems with this approach however items in GUI created/changed by one developer take some time before it is created/changed for all the others.
We could off-course develop several different projects using the same Sitecore installation but since almost all customers use different versions of Sitecore we have found this approach a bit cumbersome.
Often we set up an automated build-server but this is a whole other issue.
Reusable code and renderings
I would like to say that we create neat packages based on the same codebase that gets reused between projects but unfortunately we are not there yet. Today it is a lot of cut and pasting between solutions.
Uploading code to customer
This is done via sitecore packages, normally with some kind of dynamic selection for what files to include, say all ascx-files in a specific folder changed the last 5 days.
There you have it.
Take a look at this series.
Especially the component architecture part have increased our level of reusability.
When you create your Visual Studio's project in Sitecore's web root folder and you will keep all Sitecore's dlls files inside bin directory, don't forget to add to project's references all these files:
bin\ComponentArt.Web.UI.dll
bin\HtmlAgilityPack.dll
bin\ITHit.WebDAV.Server.dll
bin\Lucene.Net.dll
bin\Mvp.Xml.dll
bin\Newtonsoft.Json.dll
bin\RadEditor.Net2.dll
bin\Sitecore.Kernel.dll
bin\Sitecore.Logging.dll
bin\Sitecore.NVelocity.dll
bin\Sitecore.Zip.dll
Because when you CLEAN your project and you will have reference only Sitecore.Kernel.dll (in most of cases), you will lost most of dlls from bin directory!!

Zune API ZuneCore.dll

I noticed the other day that the Zune PC Software exposes a type library (ZuneCore.dll). It seems to be related to the WMPLib API in some way but I can't figure out how to use it either from VB6 or C#.
Has anybody tried this and had any luck?
Dave
May be an old question, but this link might help: http://zunelcd.codeplex.com/ If you download the source for this project one of the class libraries is a decent API for communicating with the Zune Software.
i just found out about this -> http://soapitstop.com/blogs/fleamarket/archive/2008/03/03/read-the-zune-collection-in-net-from-zune-s-own-api.aspx but it seems a bit outdated Initialize method now takes some parameters and i dont know what to put there!
Try adding a reference to it from a .NET project in Visual Studio. Perhaps this namespace will appear magically: MicrosoftZuneLibrary