I assume we must be missing a trick as we are finding using IIS Express with teams quite painful.
The issue is IIS Express' applicationhost.config is stored locally in each persons MyDocuments folder, and thus separate to the Visual Studio solution and not in source control.
So when we make a change everyone has to manually update applicationhost.config on their machine.
THe update visual studio does to the applicationhost.config file fails, because we are not using localhost, we have host entries to give our environments different names.
Is there a better way?
Refer to Here
UPDATE FOR VISUAL STUDIO 2015: As was pointed out to me in a comment
by Søren Nielsen, in Visual Studio 2015 the IIS Express configuration
files have moved. They are now separate per project, and stored in
/{project folder}/.vs/config/applicationhost.config. Which is much
better, in my opinion, just don't forget to add .vs/ to your
.gitignore/.hgignore files!
Other wise NO there is no better way. Instead of IIS Express, for remote access you can use IIS on your development machine...
It doesn't seem a big deal: when you load a project configured to run with IIS express, VS checks your applicationhost.config for that entry. If it doesn't find it, it just prompts you with the problem and asks you if you want it to create it for you. Just click "yes" and the entry is added.
At least, that's how we deal with that here. The problem is just the first time anyway, all other settings are stored in web.config in the project, which is versioned, so everything should be smooth.
Related
VS 2017 creates a file for ASP.NET Core MVC projects, called launchSettings.json, which contains information about IIS Express and Kestrel AMAIK.
We host our projects in IIS even on development machines, thus we don't really need these files.
We delete them, yet they keep coming back and each time we open up a solution, they show up.
Is there a way to prevent VS from creating those files?
As per https://developercommunity.visualstudio.com/comments/652195/view.html - just add the following property to the .csproj:
<NoDefaultLaunchSettingsFile>true</NoDefaultLaunchSettingsFile>
If you have a solution with web applications configured with IIS, Visual Studio will set up the virtual directories and point them to your code. If you have multiple branches for that solution, there will be different directories for the same IIS applications. If you open up a solution from a branch different from the one the IIS applications are currently pointed to, VS2010 would warn you and then ask if you want to change the directories. VS 2012 doesn't warn you, it just changes the directories with out asking.
Is there any way to get that warning back? Is there a way to set VS2012 to not change the directories or a tool to do it manually?
Quite often I am working in one branch but I want to look at the code in another branch. If I open that branch up in VS2012, it changes the directories in IIS and now the applications are pointed at the wrong code. 2010 would ask me so I could tell it 'no' if I didn't want it to change directories.
Thanks,
Matthew
I am using IIS Express in Visual Studio 2010 and right now it runs on localhost:61156. But I need it to run on a domain. Is it possible to make IIS Express to run on devserver.com, instead of localhost:61156? So basically when I run debug I want devserver,com, instead of localhost:61156. I've come across a few things on google, but no luck. Any ideas on how to do this?
Thanks!
Do the following
If IIS Express is running stop it
Open your webapplication project file (*.csproj or *.vbproj)
Find <IISUrl>http://localhost:61156/</IISUrl> and change it to <IISUrl>http://devserver.com:61156/</IISUrl>
Open %userprofile%\documents\iisexpress\config\applicationhost.config file
Visual Studio 2015 now puts an applicationhost.config file specific to your project instead of using the global one. It is located at: /path/to/code/root/.vs/config/applicationhost.config
Find your site entry in applicationhost.config file change the binding as shown below
<binding protocol="http" bindingInformation="*:61156:devserver.com" />
In \Windows\system32\drivers\etc\hosts file add following mapping "127.0.0.1 devserver.com"
In your browser add exception to bypass proxy for devserver.com
Note that, since you are using custom domain (non localhost binding), you must run visual studio as Administrator
#vikomall's answer is the correct one, but I don't have enough reputation to comment yet, so I'm adding an extra answer here with a clarification for Visual Studio 2015.
Visual Studio 2015 now puts an applicationhost.config file specific to your project instead of using the global one. It is located at:
/path/to/code/root/.vs/config/applicationhost.config
Follow the same steps as #vikomall's answer, but use the path above for step #4.
See Mike Dice's Blog
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 just started to use VS 2008 Express. I noticed that I cannot add a new solution folder within a solution in the way like VS 2005 Prof. Not sure if this feature is disabled in the Express version or not.
In VS 2005, I can also add project within a virtual solution folder. This makes my projects in a well organized tree. However, I cannot add virtual folder within a solution in VS 2008 (express?). I am not sure if I could add projects within a virtual folder (if possible in Prof) or not.
I even tried to use text editor to add folder structure in sln file like VS 2005 sln file. However VS 2008 complains the virtual folder.
I couldn't find a question in your post, but yes, the express edition disables this functionality. Consider it another reason to shell out the money for a higher tier.