I have solution with 3 projects. One is Website and another one is Services. I want to access page from Services project via AJAX from page on Website but i fail to do so since only one project it running.
How can it be done?
please avoid answers like "What have you tried ?" because this is general question with no relation to specific code.
I'm using IIS Express built-in with Visual Studio Express 2012.
Thanks
You can do this by specifying multiple start up projects.
Select the properties of the solution, go to Common Properties -> Startup Project.
Select Multiple Startup Projects and select the ones you need. You can also adjust the starting order.
Having said that, IIs Express serves up web applications even if Visual Studio is in debug mode or not, so this isn't strictly necessary.
Note: I don't have the Express SKU in front of me, so no guarantees that this is possible on that. If it isn't, then the answer is that it isn't possible.
Related
I have an existing solution in VS2010. When I click the properties of my project I get the view as can be seen in image1.png:
When I create a new empty ASP.NET web application and click the properties of my project I get the view as can be seen in image2.png:
A huge difference.
Now I'm implementing this code here: http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
And that tutorial assumes I get a view as I've shown you in image2.png
In image1 and image2 I've also marked the menu items: "Website" and "Project"
This makes me assume that I've created a website application whereas I need something different (I'm thinking a web application project).
Not sure what to do now, I need to convert my current application to another thing, but to which type and how to do it?
I also came accoss this post: http://blogs.msdn.com/b/webdevtools/archive/2009/10/29/converting-a-web-site-project-to-a-web-application-project.aspx
But before I start screwing up everything :P Is that what would solve my problem?
It should be possible to use either a web site or a web application project. In the example on the link you've posted, they use the predefined template for ASP.Net MVC Web Applications. This has several advantages - it sets up the structure and other resources for you - it's effectively a template.
For the purposes of the tutorial, why don't you just set up an application that way? If you've already written some code, you can just import it into the new application.
For future projects, you might want to consider which is best for your needs. Apart from structure, there are some other key differences between a web application and a web site project.
MSDN handily provides the differences here:
http://msdn.microsoft.com/en-us/library/dd547590.aspx
If you find you want the features of the web application, then the link you've posted is fine. You'll need to do some re-organizing of your references and so on and so forth, but the process is fairly straightforward (but not painless).
A "web site" in visual studio is the old, .net 1 style of creating web sites. It basically dynamically compiles the code in a folder when it's hit for the first time. Later .NET introduced a "web application" model where the code is compiled into a DLL and no code files are deployed with the site. "Web sites" are pretty much depcrated and shouldn't be used for any new projects unless you're doing a quick demo site.
The codeplex project you referenced also depends on MVC 3 (which are web applications).
You are probably better off just restarting like the tutorial says - create a new MVC application like it shows in its first screenshot.
If you do not have that option, use Web Platform Installer to add MVC for you - http://www.microsoft.com/web/downloads/platform.aspx
Good luck!
I can't tell exactly what's going on from your screenshots, but if you have a web site that you need to convert to a web application project, you can find the directions here
Although the instructions are specific to VS2005, they are basically the same for 2010 as well.
I've got a sample project that has several web services and uses them during run time. The application works as intended. The web references are can be see in the Solution Explorer under a folder called "Web References" with the list of web services as single files.
I'm trying to use these same Web Services in another solution but it's not working. I've added the Web Services to the solution and they have appeared under a folder called "Web_References". In addition, the list of web services under this appear with the extension .discomap and have 2 subfiles under them with the same name but with the extension .disco and .wsdl.
These are the only differences I can see. However, in the 2nd solution, Visual Studio cannot resolve the references to the classes from the web services (I'm using the same code as the first solution).
Does anyone know why the web references appear differently and why my 2nd solution is not allow me to use the web references that I've added?
TIA
Update: Following on from the comments, yes the 2nd one is a web site and the first appears to be a Windows Application using web services. Given it's a website, how do I use the web references?
When I start a new ASP.NET project in Visual Studio 2010, I can either create a new ASP.NET Web Site or an ASP.NET Web Application.
What's the difference between these two project types? Why would I choose one over the other?
Please note: this question is an exact duplicate of this one, but I'm asking specifically about Visual Studio 2010 (there are no answers targeted at VS 2010 in the original question). So are the answers of the other question still valid or are there any changes with VS2010 which results in different answers?
I just want to give an example that website means its a site by which we can get some information. they will be a collection of websites in a Web Application. Example take any company site. And coming to web Application the best example is Gmail. which is an application . which we use. This is the general difference between these two. Even it may also contain a collection of websites. But depending on the Requirement.
I know this question is a bit old, but just in case someone finds it..
I believe that if you want to use Web.config Transformations (useful if you want to have different setting's for development and release) then you need to be using a web application.
Technically this is probably a result of the same differences as in 2008 between a web site project or a web application project, but being that it's a new feature in vs 2010 (at least built in, i think you can get it in vs 2008 also) it's at least one new difference from vs 2008 to vs 2010 to consider when choosing which way to go.
I would recommend website only for a very simple/small application. Build times are higher, you cannot use nuget, there are no namespaces (although aspx and ascx class names can be pretty cool), no conditional compilation symbols, no immediate code tests (since there's no a single .dll to be referenced), etc.
In more complex scenarios the way to go is web application.
I'm new to developing in SharePoint and would like some tips please. I want to develop a WebPart. I understand that I effectively need to do this on a machine with SharePoint Server installed and create the web part as an ASP control. Once the control is created, how do I link it into SharePoint?
I would recommend you to take a look at the WSP Builder extensions for Visual Studio. It will simplify the development and deployment process for you, since it contains both templates for web parts, features and it will also package it up in a WSP solution for you.
I would read though this:
http://msdn.microsoft.com/en-us/library/ms452873.aspx
It will answer a lot of your questions about creating a web part, deploying etc.
If you're using the Microsoft Provided WebPart Visual Studio template...it will automatically be deployed to your site when you build it.
If you need to deploy to a test/production environment, you need to create a SharePoint Feature and then deploy the Feature to the server.
http://www.allaboutmoss.com/index.php/2010/03/22/hello-world-sharepoint-webpart-for-beginners/ helps you to create simple webpart and shows how it deploy in server.
You are able to build Web Parts in a number of different ways, through Visual Studio .NET using either the SharePoint Web Part Namespace or the normal ASP.NET Web Part Namespace further you are able to build Web Parts in SharePoint Designer using a combination of different technologies, such as XML Web Services.
XML Web Services will allow you to hook directly into SharePoint using SharePoint's Native Web Services, you can then create a Data View Web Part which will enable you to view, collate, filter and group List Items. This, of course, will also allow you to mingle normal HTML as well as XSLT syntax, allowing you to build logic into the Web Part.
The good thing about doing it this way is there is no "real' coding, i.e. no Code Behind page etc as there would normally be in ASP.NET. This also allows you keep things more or less SharePoint Centric, which is important because you may or may not have access to Central Admin or SSP nor indeed the Server itself, the 12 hive or the GAC.
How you decide to develop Web Parts should include thinking about all of the above, you may have a very restricted development environment. Further, you can also use Namespaces provided directly from GAC assemblies provided by Sharepoint, you may either need access to a development environment which has a MOSS or WSS Server on it or the PIA's or Assemblies from a MOSS/WSS Server.
I am a software developer, however, it is important for me to develop applications which are as SharePoint centric as they can be, which is why I decided to develop my Web Parts in SharePoint Designer. However, there have been times when using full VS.NET is the way to go, I would suggest you look at SharePoint Designer first, get a feel for the interface, XML Web Services, XSLT and HTML once you have created a SharePoint Designer Web Part and Provided this Web Part exists within a Web Part Zone, you can export the Web Part and reimport it into any number of Site Collections.
I must add that the above relates to SharePoint Lists and Libraries but it gives you a grounding to understand how it all fits together. it helped me understand more and made development of more coded Web Parts easier, It may not suit your individual requirements, SharePoint is a huge environment offering many paths.
Hope this Helps you out, search for SharePoint Designer... at least as a starting point.
Cheers
I'm working on building a set of ASP.NET (2.0) web-services to be deployed into a single web application under IIS7. The services will be added incrementally (over a period of a year or more) by multiple programmers. How should I organize my source in VS2005.
Should I use one project or several?
Should I use a Web-Application or Web-Site project.
How do I manage the web.config that they will all share.
Thanks for your advice.
Do you use source control now? All of your "control" problems are solved by any decent source control system (i.e., not VSS).
I'd put them into a single project assuming they have code and types in common between them. For instance, if they use the same data access layer and underlying database.
I would never use web site "projects" for web services. Any of their advantages are advantages for web sites made up of web pages, and not for the more complex requirements of web services.
I'll speak to how our shop handles this, which I find to work well.
We use several projects. One for each web service. This allows us to publish one service without effecting the others. We're also on VSS (bleck!) which makes for less conflicts.
We use a Web-Site project and it works fine
We manage the web.config by doing a diff on the file before we publish. The web.config's are something that rarely change