Develop Reference

Looking for solution for cross platform development windows application and web application

I got project that will run on windows and web. I wonder if there is a solution to create that as a cross platform application . If you have any experience or any solution please let me know.

Create web service(s) for your business.
Consume them in both windows application and web application.
Configuring is the key here.
When it comes to consuming web services,may be little challenging for authentications, authorizations and marshalling data, but it is possible.
You can choose any programming language for creating web services. But languages like Java, C# or vb.net has good supporting libraries and easy to do. Any how your question tag says C#, dotnet frame work has good support for webservices using WCF.

You can share a lot of UI code between a desktop and web application using a framework like Electron. This is the method that a lot of popular products with both web and desktop apps (like Slack, Discord, and Ghost to name a few) use.

Using multiple programming languages in a ASP.net Web Application

I've a Web Application project that uses VB as programming language. I want to keep using this language due I've more experience and also it works better with IntelliSense.
Anyway, now I am using Open XML SDK 2.0 Productivity Tool for generate code for the generation of a OOXML document through a given template, and this tool only generates C# code.
With the aim to mix both languages in my project, I had followed this tuto but when I try to add a new C# class, the only language that appears in the list is Visual Basic as you can see in the attached screenshot.
Does anyone know how I can fix this?
Thank you very much

This is not possible; you cannot mix C# with VB.NET in the same project. When .NET compiles an assembly it can use only one compiler to do so.
What you can do, is have a solution with multiple projects (for instance one Web app and several class libraries), and then you can have each class library in the language of your choice.

As others have said in general you cannot do this. The one exception is a web site project.
There is a difference between a web site project and a web application. Mainly in the way they are compiled. A web site is what the tutorial you linked talks about (note the way they say to create it via new website rather than new project and choosing web app) whereas you say above that you have a web application.
You have the option of either changing to a web site or using supplemental projects as others have suggested.

Mixing languages is not what I would go for.
Add a new (DLL)project to your solution that uses C# and handles your XML.
Reference that C# project from your VB-app and call into it.
Clean and easy.

You need to install Visual Studio for c#. It looks your current installed language is vb.
Here is link for downloading vs:
http://www.microsoft.com/visualstudio/eng/downloads#d-2010-express
About using vb and c# code in same solution, its possible as long they are separated to different projects.

Using ASP.NET MVC as Web Service

Does anyone have experience using ASP.NET MVC project as a Web Service?
i.e. using ASP.NET MVC without Views, so other applications can use the URL to GET or POST to the actions in the Controller.
Has anyone used it? If so, are there any drawbacks for not using Web Service project instead?
Thank you all in advance!

It really depends on the kind of application you're writing. I would actually argue the inverse of LukLed's position - SOAP-based services are better suited for internal clients when you want to support things like Windows Authentication, or different protocols like TCP or MSMQ.
Using a more web-style of GETs and POSTs around specific "resources" starts to get you into the REST architectural style. This technique has a few distinct advantages to me:
The response is usually smaller, particularly when using lightweight formats like JSON
Because of the simplicity of the requests and responses, this makes it much easier to use in mobile / native applications (see Twitter's API, for example)
The service you create can be self-describing and discoverable, because you can link to other parts of your API just like normal web pages.
One article that particularly helped me understand the tradeoffs here is Martin Fowler's "Steps Toward the Glory of REST." That being said, it may or may not be the right fit for your application.
If you do choose to build a more REST-based service, definitely consider using the ASP.NET Web API built into MVC4 as others have mentioned. It's currently in beta, but Microsoft felt good enough about it to give it a go-live license.
UPDATE:
Since ASP.NET core, ASP.NET web API has been integrated into MVC 6 project.
https://wildermuth.com/2016/05/10/Writing-API-Controllers-in-ASP-NET-MVC-6

If you want to use simple GET and POST calls, MVC will be good choice. ASP.NET MVC 4 will have support for creating HTTP based APIs. You can read about it here: http://www.asp.net/web-api
Web Service created in Web Service project can be easier to consume, because it can generate WSDL file, that can be easily read and used in many different languages (by using SOAP protocol). On the other side, WS can create huge XML responses, that could be many times smaller, if you used your own format.
If you want to spread your web service around the world, allowing SOAP will make life easier for many developers. SOAP can be used by people, who almost have no idea about programming. If you'll use it internally, prefer speed and simple requests and responses, you can use MVC.

New ASP.NET MVC includes Web Api Kit, which can do exactly what you want. With current version you can still use it. There are no real drawbacks to it

referencing asp.net c# classes/methods in silverlight project

Does anyone know how to do this? I built a backend c# class in asp.net but want to access these same classes without recreating them in silverlight. Is this a possibility?

You can reuse the cs files by adding them to your project AS LINK. Right click in your project and select Add Existing...Browse to your file and in the Open Button, use the pulldown arrow on the right to select Add As Link. You will see the file added to your project with an icon that with the little Windows Shortcut icon overlayed on it.
Just remember - the ASP.Net runs on the .Net runtime. Silverlight runs on the CoreCLR (Silverlight runtime.) Not everything that compiles in oone will compile in the other...
To separate things a little bit, #if directives can help, you can also use Partial Classes and partial methods (to add content that only runs on the server or on the client.)

RIA Services is definitely the way to go for sharing code between ASP.Net and Silverlight.
As well as the previously mentioned generation of domain service models, it also lets you share individual files between the web-app and Silverlight by simply inserting "shared" in to the filenames. e.g. "MyClass.shared.cs".
RIA services does not take long to get to terms with (and there are good tutorials about). Try this one.

Well, ASP.NET itself isn't going to work (ditto many of the full libraries), but I'm assuming you just mean you local domain model etc.
IIRC you can try to simply reference it, but it may well generate a warning message. Of course you need to be exceptionally careful not to use anything that the other platform doesn't support...
IMO, the better option here is to create a second csproj that includes the same .cs files (or cheat with a wildcard/deep include). And build both. Same C#, different dll/platform.
Is isn't uncommon to find that you need a very small usage of #if directives, too.

WCF RIA Services may help you solve your problem. Silverlight does not use the same runtime as ASP.Net does and you cannot directly share assemblies containing model classes on the client and the server side. To solve that WCF RIA Services will transparently generate classes on the client side based on model classes on the server side. Obviously WCF RIA Services will also allow you to create, read, update and delete objects of these classes using a web service.
MSDN has more specific information about WCF RIA Services Client Code Generation.

REST from asp.net 2.0

I just built a asp.net 2.0 web site. Now I need add REST web service so I can communicate with another web application. I've worked with 2 SOAP web service project before, but have no experise with REST at all. I guess only a coupleweeks would works fine. after googling, I found it's not that easy.
This is what I found:
There is NO REST out of box of asp.net.
WCF REST Starter Kit Codeplex Preview 2 base on .net 3.5 and still in beta
Rest ASP.NET Example
REST Web Services in ASP.NET 2.0 (C#)
Exyus
Handling POST and PUT methods with Lullaby
ADO.NET Data Service
...
Now my question,
a) Is a REST solution for .net 2.0? if yes, which one is best solution?
b) if I have to, how hard to migrate my asp.net from 2.0 to 3.5? is it as simple as just compile, or I have to change a lot code?
c) WCF REST Starter Kit is good enough to use in production?
d) Do I have to learn WCF first, then WCF REST Starter Kit? where is the best place to start?
I appreciate any help here.
Thanks
Wes

If your looking for a project that templates a REST service, you're correct in saying there is no out of the box solution. However, RESTful web services are possible using WCF. The key part is to use several attributes when defining your service functions that let the .NET framework know that the function is not expecting SOAP. The main attribute to use is the WebInvoke attribute.
Here is an example from developer.com:
[OperationContract]
[WebInvoke(Method = "PUT", UriTemplate = "/admin/post/{id}")]
void UpdatePost(string id, Post post);
The above code will actually be defined in an interface for your web service. The interface is created automatically when you create your WCF web service project. The actual code for the function will be placed in the class used to implement the web service.
Check out the article on developer.com for a full tutorial. It might seem overwhelming at first if your new to WCF, but after you dive into it, I'm sure you'll start to pick things up quickly. Here is the link for the artile: http://www.developer.com/net/article.php/10916_3695436_1
To answer all of your questions,
a) In .NET 2.0 you should be able to build RESTful services using WSE2.0, but if you have the option to use .NET 3.5, I would strongly recommend going the route of WCF since it is much easier and is designed with REST in mind.
b) Converting your project won't be hard at all. It's just a matter of targetting the new version of the framework in your project settings. Converting a web service from a WSE2.0 service to a WCF service will be a bit trickier though. The easiest way to do so would be to copy the code from each of the different web service functions into the class where you implement the new version of the function. Copy-Paste shinanigans :)
c) I'm not sure what this starter kit is that you're referring to. RESTful web services should be fully supported in WCF which was fully released as of 3.5
d) It would be helpful to understand WCF at least a little before beginning, but it's not crutial to understand it completely in order to get started. I would recommend just reading through the MSDN article on WCF at least once, and then begin working. I'm sure you will come across other questions as you begin, but you can look up those parts as you come across them.
Anyway, I hope this information helps. Good luck to you.
Edit
Some improvements have been made in the REST world. As Darrel Miller mentioned in the comments, WCF was not in fact built with REST in mind. I mis-spoke previously. In fact the framework is built with SOAP in mind and the WebInvoke attribute fills the gap. Although there is a lot of debate around the topic (Web API vs WCF REST), ASP.NET Web API is a new option for building REST services in .NET. I would strongly recommend that anyone who reads this post and is able to use .NET 4.5 in their project look into it as an option.

If you want a framework built with REST in mind, you should have a look at OpenRasta...
http://openrasta.org/

You could look at using ASP.NET MVC as a RESTful web services platform. WCF is probably the way to go in the long run, but MVC should easily handle it. Your actions would just need to be set up to return JSON or XML, depending on how you want to serialize it. MVC offers both a JsonResult and fully customizable ContentResult -- i.e., you serialize your response to a string property on the result and set it's type and encoding.
NOTE: MVC does require 3.5 SP1 so it's not going to be a 2.0 solution. If you require 2.0, you'll need to look elsewhere.

Use WCF REST.
You can use it today. The WCF REST library is ready to go, usable in production.
The WCF Starter Kit (see http://msdn.microsoft.com/en-us/netframework/cc950529.aspx) is something else. It delivers extra stuff; it includes a set of VS project templates, docs, samples and a few tools for building REST apps (client or server) with WCF. One cool tool is the "Paste Xml as Type" command add-in to Visual Studio.
On the other hand, building a REST client, in the general case, I'd recommend taking advantage of the HttpClient assembly in the starter kit (Microsoft.Http.dll). It's small, simple, and useful. A low-risk and high-value dependency even at the current "preview" status of the Starter Kit.
If you were consuming just a single REST service, then you don't need the general Microsoft.Http.dll assembly; you can do all the stuff it does in some code that uses WebRequest. But if you wanted a more general flexible class for manipulating client-side REST requests, then grab that Microsoft.Http.dll.

I'm not sure about a REST solution for 2.0. So I think WCF is going to be the way you'll have to go with this one. MSDN has a long introduction to it.
My personal philosophy is that if a technology is still in beta then I would rather not use it for something that will potentially be a production application so I would start with WCF since it was introduced in the 3.0 version of the framework.
3.0 and 3.5 is actually an update to the libraries, but the CLR is still 2.0 so if the libraries you're using are not deprecated or changed in the new frameworks it should be okay.

Take a look at this CodeProject for a starting point. It seems somewhat... hacky. Modernizing to WCF would be cleaner.

REST, or RESTFUL
Adding this to the System.Web in web.config will enable http get, and put.. aka REST-Like... but not full rest.
<System.Web>
<webServices>
<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
</protocols>
</webServices>
</System.Web>