Answered by:
Repository Structuring

Question
-
I have an ASP.NET MVC3 application in a GIT respository that I want to push as an Azure web site. The repository is structured something like this:
- Repository-Root
├───stuff
└───src
│ MyProject.sln
│
├───Myproject
│ MyProject.csproj
│
├───MyProject.Web
│ MyProject.Web.csproj
│ Global.asax
│ Web.config
│
├───MyProject.Azure.Tests
│ MyProject.Azure.Tests.sln
│
└───packages
What I'd like to know is:
- What is the proper way to ensure GIT knows which Visual Studio solution to build? I want it to build the one immediately under the 'src' folder
- How do I address the fact that my web-entry point, in path 'src/MyProject.Web/Global.asax', is not at the root of the repository?
- I don't want my nuget fetched binaries to be part of the repository. What special steps must I take to ensure Azure will know to automatically fetch my nuget package dependencies after a GIT push? Again, please notice the current path to my
package info is 'src/packages'.
-Brent Arias
- Edited by Brent Arias Wednesday, October 3, 2012 4:54 AM typo
Wednesday, October 3, 2012 4:53 AM - Repository-Root
Answers
-
Hi Brent,
For #1 and #2, see https://github.com/projectkudu/kudu/wiki/Customizing-deployments.
For #3, right click on your solution in VS and enable NuGet package restore.
thanks,
David- Marked as answer by Brent Arias Friday, October 5, 2012 4:24 PM
Wednesday, October 3, 2012 11:07 AM -
I have added some clarifications to the doc about it pointing to the project and not the solution. It could always say more, but I do want to keep it focused on what is Azure git specific info, without getting to deep into general knowledge about msbuild.
In the end, all users need to know to be successful is to point to the csproj, and hopefully my latest clarification makes that clearer!
- Marked as answer by Brent Arias Friday, October 5, 2012 4:12 PM
Friday, October 5, 2012 4:10 PM
All replies
-
Hi Brent,
For #1 and #2, see https://github.com/projectkudu/kudu/wiki/Customizing-deployments.
For #3, right click on your solution in VS and enable NuGet package restore.
thanks,
David- Marked as answer by Brent Arias Friday, October 5, 2012 4:24 PM
Wednesday, October 3, 2012 11:07 AM -
I've followed your instructions, but it didn't work. After the push, shown below, browsing the site produces "You do not have permission to view this directory or page" message.
$ git push azure master
Password for 'https://Mystagogue@structure.scm.azurewebsites.net':
Counting objects: 99, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (92/92), done.
Writing objects: 100% (99/99), 646.54 KiB, done.
Total 99 (delta 15), reused 0 (delta 0)
remote: New deployment received.
remote: Updating branch 'master'.
remote: Preparing deployment for commit id '36dab77aad'.
remote: Preparing files for deployment.
remote: Deployment successful.
To https://Mystagogue@structure.scm.azurewebsites.net/Structure.git
* [new branch] master -> masterAs can be seen, there was no build and no nuget exercise - despite NuGet package restore having been enabled and the .nuget folder being part of the repository:
•Repository-Root
├───stuff
└───src
│ MyProject.sln
│
├───Myproject
│ MyProject.csproj
│
├───MyProject.Web
│ MyProject.Web.csproj
│ Global.asax
│ Web.config
│
├───MyProject.Azure.Tests
│ MyProject.Azure.Tests.sln
│
└───.nuget
NuGet.Config
NuGet.exe
NuGet.targetsWorse, the "you do not have permission" is caused by a lack of a default file for IIS to work with - in this case the global.asax. I think I know why it can't see it.
First, I have more than one solution in my repo to disambiguate, so I need to point to the folder that has the target solution:
[config]
project = src...AND the project site root needs to point to the global.asax:
[config]
project = src/MyProject.WebI cannot have the '.deployment' file configured both ways at the same time. If you tell me that Azure/GIT is smart enough to auto-adjust the site root or move necessary files (e.g. global.asax), then perhaps that is ok. Perhaps then the first item to address is why nuget is not auto-fetching; which may translate to "why didn't it attempt to build the site?"
I could send you my repository - it was created merely to test azure; because it has no functionality to speak of, it is a tiny repository.
-Brent Arias
- Edited by Brent Arias Thursday, October 4, 2012 12:09 PM Clarify structure
Thursday, October 4, 2012 12:03 PM -
Did you try pointing project to the csproj file, as suggested in that document? If so, what was the output of the push? You give some output above, but don't state exactly what you had in the .deployment, so it's hard to know what's going on.
If that doesn't help, then yes, sharing your repo (e.g. via github) would be ideal for investigation.
- Proposed as answer by David Ebbo Thursday, October 4, 2012 6:28 PM
Thursday, October 4, 2012 2:08 PM -
I had the .deployment set like this:
[config]
project = src...in order to point to the folder containing the Visual Studio solution. On your prompting, I changed it to this:
[config]
project = src/MyProject.Web/MyProject.Web.csproj...and then it worked! Very confusing. I would expect that it needs to know where the Visual Studio solution file is. Why does it not need to be told that?
-Brent Arias
Thursday, October 4, 2012 5:29 PM -
msbuild actually doesn't need the solution in order to build. e.g. try going straight to your csproj and run msbuild on it from the command line.Thursday, October 4, 2012 7:05 PM
-
True, msbuild only works with project files (and converts a VS solution file into a project file on-the-fly), but I would not have anticipated the solution file is therefore superfluous. Indeed if it were superfluous, msbuild would not have been given the ability to convert a solution file into a project file.
Maybe I'm picking a bad example, but I believe it is the solution file - rather than project file - that keeps track of whether the last build was debug or release. If I wanted to push a debug build to Azure, I might presume to handle that through the solution file; just set to release, save the solution, commit and push.
I don't doubt that my comments and example may raise a whole set of "that isn't the right way (on Azure)," but I would take this opportunity to request the '.deployment' instructions or related documentation explicitly state that the solution file can be ignored. If the rationale given is "because msbuild can build project files directly," it will still leave unanswered questions. Fresh documention with clarification(s) about VS solution files should rather underscore how "features" of a solution file are or are not supplanted with some other technique (such as how to select debug or release).
For example, I invite the link above to have a comment that says something like: "Although the .deployment file is never pointed to a VS solution, the capabilities X, Y, and Z offered by a solution file are retained by using technique M and N; whereas capability Z is not supported at this time." Here "capability" might be something like the ability to choose a release or debug build.
BTW, thank you for your help!!!!
-Brent Arias
Friday, October 5, 2012 3:41 PM -
I have added some clarifications to the doc about it pointing to the project and not the solution. It could always say more, but I do want to keep it focused on what is Azure git specific info, without getting to deep into general knowledge about msbuild.
In the end, all users need to know to be successful is to point to the csproj, and hopefully my latest clarification makes that clearer!
- Marked as answer by Brent Arias Friday, October 5, 2012 4:12 PM
Friday, October 5, 2012 4:10 PM -
I really appreciate the clarification you added to the documentation. It did an excellent job of meeting your requirements, while simultaneously not creating more questions than it answered. In short, I'm very glad you briefly gave the rationale.
-Brent Arias
Friday, October 5, 2012 4:14 PM