I am currently working on a solution which has an ASP.NET application and a Web Service. Whenever I open this solution I get the message that the virtual directories for this project have not yet been created and must be to continue. The problem is, if I hit OK, it cannot create the directories because they already exist and then I cannot load the project. Looking in IIS I can see that the virtual directory exists in C:/Inetpub/wwwroot/ProjName. If I delete this from IIS, I can then open the project, but it creates the virtual directory in C:/location of project folder. When it uses the project's location, I am not able to connect to the site or the web service.
The same thing happens on XP with IIS 5.1, VS 2010 and Server 2003 with IIS 6.0, VS 2010. Similarly, it happens on colleague's machines, so I am convinced that it is a setting in VS, and not IIS or my machine.
Right now, my solution is to delete the virtual directories, open the VS solution, delete the virtual directories, and publish the projects with the publish toolbar in visual studio (not the web tab in project properties).
I fear that I've at some point messed up a setting on both of the projects, but it has been some time since I've been working around this. I've scoured all of the settings and I can't find anything that fixes this behaviour. I need to pass the project along to someone else, and I feel as if the work around instructions may be confusing so I want to fix this.
I used to do things similarly back in the days when VS didn't have its own dev server - re: directly work on web projects in a local version of IIS (if memory serves, this was called "Personal Web Server" or PWS - am I advertising my age?)
Anyway, I haven't (thankfully) done that since VS (2005?) got its own dev server...
Try this process in VS 2010:
You can develop your solution on any local folder in your file system. You can run/debug your solution from VS (ctrl f5 or f5 respectively) - it will use VS dev server by default. Your development machine doesn't even need to have IIS...
After you are done developing and debugging (using VS and its dev server), you can publish to IIS or even to some other "publish folder" in your (local) file system, and simply copy the files to whatever (local/remote) IIS virtual (ASP.NET application) folder you prefer.
Related
I have a Visual Studio "solution" which contains a Web application project (among a few other projects). Visual studio "typical" setup seems to be to insist that the output directory for binaries is smack in the root of the project source directory. In particular, each time the web application project is opened, Visual Studio will reset the physical path of the IIS virtual directory to point to the project directory.
This is problematic on many levels:
It's never wise to mix binary output directories and source trees
If the web application is buried deep within a directory hierarchy of other source, wherein many projects produce libraries which may be used as support libraries in the web application, then all the other supporting projects must have their binary output directories set to a bin directory a some non-obvious, nonsensical location somewhere in the source tree.
This "typical" VS setup does not have your web app setup duplicate the "production" setup you would get from a publish: there may be files in your source tree (an old .js file there there from a repository extraction, for example) that are not referenced in your projects, and so would not be in the production published package, but are there in your debugging setup.
It is very possible and very easy to configure all the projects in a Visual Studio solution to build to a bin directory in some subdirectory cleanly placed outside the source tree. It is also easy to ensure that the web app build places all content cleanly in this directory. It is also easy to configure an IIS virtual directory to point to this build output directory. And then Visual Studio, unannounced and unbidden, screws this up by arbitrarily changing the physical directory of the carefully configured virtual IIS app, to point to the middle of one's source tree.
How can this crazy-making behaviour be stopped? I.e. how do I prevent Visual Studio from automagically re-setting the physical path of the virtual web directory each time the web app project is opened?
This question has been asked many times here on Stack Overflow, but I have seen no real answers:
The response to this question (IIS8.5 is automatically changing Physical Path property) simply indicates how to control the order in which Visual Studio does its repointing.
This question and response (Visual Studio creating IIS virtual directories when solution opened) simply confirm the behaviour.
The response to this question (Opening projects changes iis settings) is simply wrong, as are some of the comments.
These questions (Visual Studio 2012 changes IIS application directory without asking), (Visual Studio changes local IIS configuration) have no responses.
Basically, no one has said it can't be done, but no one has give a decent solution either.
I have my application in IIS pointed at %SystemDrive%\inetpub\wwwroot\web, and would like it to stay that way. Like others, I discovered that every time I opened the solution in Visual Studio (I'm using 2017), it would change the application's path in IIS to point to the path that Visual Studio uses.
I've made the following change to the project settings (web tab) for my project. In the servers section, I've set the drop-down to "External Host", and then entered the project URL as https://localhost/web. I'm now able to open the solution in VS without it updating the path in IIS.
We currently have a very large Classic ASP website that is critical to our business. It is kept in Visual SourceSafe for version control and we have numerous developers who develop the site in Visual Studio 2005. We open the website with VS2005 directly from the Development web server. We can check the files in and out of VSS directly through VS2005 and all changes we make to the asp pages are visible on the development website immediately, without the need to check back in or copy any files.
We would like to move forward with VS2013 and TFS. Our newer websites are all in TFS and we want to standardize.
Is there a way that we can continue developing the website directly on the web server using VS2013 integrated with TFS? I have found number of articles and responses online about TFS and ASP.NET, but since we don't build classic ASP code, these don't seem to help us.
Really your development server is not where you should be doing your development, but on your local desktops, and then deploying to your development server for initial testing.
However with that said, it looks like your working directory in SourceSafe is where you have IIS pointing to on your development server. You can do the same thing with visual studio and TFS. Just have your Visual Studio workspace pointing to the same location, but checking in everything to TFS.
Edit- the bin directory for a project typically doesn't get checked in to TFS. The developer would have to make sure they build the project every time they wish to view the site on this development server to populate the bin directory.
I have a problem which I thought could be common, searched the web for it but found nothing.
We're using a shared development machine, and every developer connects through RDP and has his own profile, desktop, etc.
The problem I am encountering is with IIS express. Since it is configured at user level (applicationhost.config inside documents/iisexpress/config) and the port configured must match the one declared in the .csproj file, two developers can't possibily run on the same port, as it gives the error "the port is already in use".
So to make it work we have to manually change the port both on the csproj and in the applicationhost.config for every developer, but it's only a temporary fix as when we commit our changes to SVN, the csproj file gets merged, so we have to do this process every time someone commits/updates.
My question is: is there a clean way to use IIS express with Visual Studio 2010 on a shared development machine?
Thanks.
Partially tested answer. Not sure how it'll work on a multi-user workstation. It might give you, or someone else here, a jumpstart to a proper solution that works best in your existing environment.
It appears that Visual Studio stores all the web configuration in the csproj/vbproj and IISExpress stores its configuration in %userprofile%\Documents\IISExpress\config\ApplicationHost.Config.
Normally, we store the csproj files in source control, but ignore the csproj.user file so that each person may have some unique settings, such as the web configuration.
Each user who signs into the box must have their own profile.
Each profile must have their own copy of the source code.
Each user's copy of the source will contain their own csproj.user file.
Ignore .**proj.user* files in your source control.
Copy the web settings into the csproj.user by unchecking the option Apply server settings to all users and then commit to source control.
Each user who pulls a copy of the source will have to configure their web settings, use a unique port that the others users are not using, and uncheck the box above so that their configuration is not passed on to the other users.
Doing this, Each profile will have their own IIS Express ApplicationHost.Config configured with a port that is different from the other profiles. Each user's copy of the source will have a csproj.user that is configured with the same port in their profile's IIS Express configuration.
For reference:
I've tried changing IIS Express's ApplicationHost.Config to use a different port than what Visual Studio expects and Visual Studio is unable to connect the debugger to IIS Express.
How IIS Express's configuration works: http://msdn.microsoft.com/en-us/library/ms178109.aspx
The best option you can use is to take advantage of the Import functionality built into MSBuild.
Essentially, you would create a seperate build target for each user. You can then import this target from this referenced file directly. I would then recommend creating this file on the server (for each user), but leaving it outside of source control.
This should allow each user to have a custom IIS port without conflicting with others.
I think you can create subdomains for each user and implement the required changes and do the testing. In this way each user can his own subdomain and port and hence work independently on the shared IIS Express.
You probably won't like my answer but here's my thoughts:
As you noticed, the configurations are tied to the user profile and not the server; this is because IIS Express is not intended to be used as a shared development server. You should be using full IIS.
I do not see any benefit or reason to use the same physical box for development. Admittedly, I don't know all the details of your scenario with licensing or workstation resources, but it doesn't seem like you gain much from having everyone RDP into the box to use Visual Studio - each person still needs a license, performance will be slower, and you shouldn't be working on the same project instance.
You should seriously consider your entire setup for development:
Each developer should use Visual Studio on their workstation, and debug/test there using IIS Express (configured with the same ports and settings across all machines - very easy).
From there, your developers should check their code into source control, and examine conflicts that may or may not arise. I'm not sure about SVN but the MSBuild automation available in TFS can be use to setup a continuous build policy that deploys to a common IIS installation so that your merged code is tested and usable from the full IIS installation mentioned above.
Anything else would be a workaround/hack that will bite you in the butt later.
I have a web service that Visual Studio just won't let me add to my solution.
If I right click on the solution, click Add, then Existing Project, then I navigate to my project, select the Visual C# Project file, I get "The local IIS URL http://127.0.0.1:8099/ specified for web project has not been configured.
It asks if I would like to create the virtual directory now.
If I choose no, nothing happens
If I choose yes, creation failed error, could not find the server http://127.0.0.1:8099 on the local machine.
Creating a virtual directory is only supported on the local IIS server.
Does anybody know how to fix this? I've been struggling with it for a while. Thanks
I have a problem with debugging my Silverlight 4 (hosted in ASP.NET MVC2) in Visual Studio 2010. It was working fine until I tried remote debugging. After a lot of hassle I managed to configure remote debugging but it worked only occasionally. So I created a new app and copied my classes one by one, but now I see I cannot debug not only remotely but also "locally" in development server. Breakpoints in Silverlight code says "The breakpoint will not currently be hit. No symbols have been loaded for this document." Strangely enough, if I run my app it will show my previous code results. (It may be relevant, before this problem I noticed that my app doesn't update immediately when I publish to remote web server. So I did the following for all projects in the solution:
//In AssemblyInfo.cs in Properties folder
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.*")]
I'm adviced that it will automatically generate version numbers so, when I publish to remote server it will immediately take into effect, which seems working well.)
However, if I change development server's port number, in the properties page of my ASP.NET MVC app, then I'm able to debug locally (about remote debugging I just gave up). But, it didn't last long; after some updates in my code the problem suddenly reoccurs. I guess development server deploys my app somewhere in a folder per port number, but where? May be, if I delete that folder, will the problem be solved? Can somebody advice me what to do?
There seems to be bug in Visual Studio 2010; see:
silverlight 4, dynamically loading xap modules