Suggestion: do not store a Web Role's "Launch Browser" preference in the Azure project file

Question

I have a suggestion: do not store a Web Role's "Launch Browser" preference in the Azure project file.
Instead store it in a hidden file, just like Visual Studio Solutions have .suo files.

The details:

1) I created a new Windows Azure project and added two web roles - MySite1_WebRole and MySite2_WebRole
2) I'm the main developer responsible for MySite1_WebRole so I typically right click on Roles/MySite1_WebRole and check "Launch Browser".  Since I rarely work on Roles/MySite2_WebRole, I right click on Roles/MySite2_WebRole and un-check "Launch Browser"
3) I see these preferences are saved to MYAZUREPROJECT.vbproj

Saving these preferences to the project files causes a few problems - here are some examples -

I'm using source control so the project is typically read-only.  Since these preferences are being saved in the project file, I now need to check out the project file.  Now some other developer working on Roles/MySite2_WebRole will not get a browser launched for his/her role.  He may need to check out the files as well - and we could play this thug-of-preferences for a long time.

Alternatively I could make my project file not read-only temporarily - but that's a mess, since now I may not get real updates in the project file.  Or I could always write to the project file and merge changes as needed - but that gets ugly for the same reasons above.

Here's the way this should be handled

In Visual Studio 2008, if I have multiple projects in a Solution I can right click on the Solution > Properties > Common Properties > Startup Project.

Now, let's say I make a change and choose "Multiple startup projects" instead of "Single startup project".

If I now save, these preferences are saved in the solution.suo file - NOT the solution.sln file.

Answer 1

Thanks for the valuable suggestion. I will pass it to the product team.

---

Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 2

We actually use the user file of the cloud service project to store this setting and the user file is not checked in. We don't write any information to the role project.

Under the cloud service project folder do you have the user file (extension .ccproj.user)? If you changed the Launch browser option, this file usually contains a property group with the name: WebRoleSkipLaunchInBrowser.

What is the new data you see getting written to your project (MYAZUREPROJECT.vbproj)? You can get to it by comparing against the latest version.

Knowing this data could help us figure out the reason behind your project being checked out.

Thanks,

Answer 3

It doesn't look like the file MYAZUREPROJECT.vbproj is being changed when I uncheck "Launch Browser" in one of the web roles.  I did a diff and don't see any differences.

But Visual Studio is prompting me - saying the file MYAZUREPROJECT.vbproj file is read-only and whether I should "Overwrite" it or not -

  - If I choose overwrite, the MYAZUREPROJECT.vbproj file is no longer read-only - causing some of the problems I mention above (this is where I did the diff).
  - If I choose cancel, my change to "Launch Browser" is not applied.

So maybe you're not making changes to MYAZUREPROJECT.vbproj- but Visual Studio definitely thinks you are.

Answer 4

Sounds like an issue with the source control provider, could you try disable your scc provider and redo your repro steps but before your un-check the launch in browser on the web role you should make both the ccproj file and the vsproj file read-only.

Thanks,
Ole

Answer 5

I am not using any source control provider - I use an external source control client (Vault).
I do have a few add-ins enabled: Rockscroll, Tabs Studio and Visual AssistX - I'll disable them and see if I can reproduce.

Answer 6

Hi Emmanuel,

It sounds like you are checking in the ccproj.user file (i.e. ccproj, the cloud service project file, not vbproj, the role project) - if I try to repro your situation just by setting my files to read-only I only see the problem you describe if the ccproj.user file is readonly (it just says the ccproj file is read only, not that the ccproj.user file is read only).

So if you don't check in that ccproj.user file which you shouldn't as those settings are not intended to be stored in SCC you should be good to go.

Let me know if you continue to see issues.

---

Jim Nakashima, Microsoft. (This post is provided "as-is")