Our ASP.NET web shop is starting to move from VisualSourceSafe to Subversion (VisualSVN/TortoiseSVN).
Subversion needs to have all files residing in a single directory tree. This is simple when using a Web Application Projects - everything lives in
\Visual Studio 2008\Projects\MyProject
With a Web Deployment Project, though, it's a bit of a mess. You have
\Visual Studio 2008\Website\MyProject for the website itself
\Visual Studio 2008\Projects\MyProject for the solution file
\Visual Studio 2008\Projects\MyProject\MyProject_deploy containing a complete "deployment" version of the website
What's the best practice for managing this in SVN? Should I just move the website under \Visual Studio 2008\Projects\MyProject and add the whole thing to the repository, including the deployment version of the site?
Best practice is to leave your solution file at the root of your project structure, with every project in a sub-folder. That way, each project can be checked out individually without the solution file if people wish to do so.
So in your case, you should have, in your SVN repository, something like:
svn://{repository_root}/MyProject/Website/ {all website files including the .proj file}
svn://{repository_root}/MyProject/WebsiteDeployment/ { all deployment files including .proj file}
svn://{repository_root}/MyProject/MyProject.sln
So the answer to your question is yes, you should move everything under a folder called "MyProject".
Edit: you should also consider having MyProject/Trunk, MyProject/Tags, and MyProject/Branches, which is considered best practice according to the SVN Manual.
Related
Here's my setup. I have a classic .Net website, not web app. I have all my compiled objects in a self-hosted nuget repo. When I build in VS, it looks at my packages and copies the binaries to the bin folder but when I try and build in Azure DevOps it's not working. My Nugets restore just fine but I haven't hit on the right msbuild arguments to make it work. I know that .Net websites are not common these days. I found this (How to use NuGet packages with an ASP.NET Website on CI Server) which was a path I was considering (putting .refresh.dll files in source control) but it seems like there should be an easier way.
How do I get my nuget packages copied to bin during a build for a asp.net website (not web app)?
What you are considering (putting .refresh.dll files in source control) is the most appropriate way.
From here:
They are simple because if you view them in a text editor, you’ll see
they contain nothing more than the full path to the dll.
Turns out, these dll.refresh files are an exception to the rule, and
they should go into source control. Its the only way your web project
will know where its references live.
For building and package restore to work, you can keep the bin folder and any .refresh files. You can remove the other binaries from your version control system.
Hope this helps.
Me - Front End web developer with an ok working knowledge of writing VB.NET code but I have never built a .NET project from scratch using Visual Studio.
External developer - Experienced VB.NET developer but completely new to version control and TFS. Also extremely cheap and prone to infuriatingly poor programming practices. He does things that make you bang your head on the table.
Background
Our external developer has coded our site but over the last few years I have been tweaking aspects of pages and have managed to learn quite a bit of VB.NET along the way. He has never used source control and I don't think he's ever had to work with another developer before.
Up until now he has maintained a local copy of the website. He makes changes to this local copy and when he wants us to test it he uploads the relevant files to our dev server. I have no experience of Visual Studio projects/solutions so if I have made tweaks to things I have edited the aspx/asxh/config files in my preferred editor and then uploaded them to the dev server. If everything works correctly I ask him to download them from the server so he can update his local copy.
I have been maintaining a local git repository of the website for the last 2 years. If he makes a change I check it in.
Obviously this is a nightmare to work with so we have now insisted that he starts using version control. I recommended GIT but he has decided to use TFS.
He has now put his solution and all the files into TFS. I have installed Visual Studio 2015 and successfully connected to TFS. I have mapped the files from source control to my own workspace but I am now at a loss as to what to do next.
Questions
As soon as I open the .sln file he has uploaded it says I have checked out the file and made changes. When I check the diff it seems to be because I am using a newer version of Visual Studio than he is. Does the .sln file need to be in version control? Or are we suppose to maintain our own versions of the .sln file and simply check in everything else?
If I try and build the project it fails because the web.config is set up for his machine and not mine. How can we maintain 3 versions of the web.config file? One for my local, one for his, and one for our dev/live environments?
I am not convinced he will have added the project to TFS correctly because he's never used it before. This is basically the blind leading the blind.
Question 1:
You need to put the .sln file in version control. Before check out the .sln file, please do a "get latest" step, which will make sure both of you are working on the latest version. When you try to check your local version in the server, and he had uploaded his local version in the server. You may have to solve conflicts before the check in.
Question 2:
You should build your project and published the website on the server. The build agent will only maintain one version of the web.config file. If he has built the project with his web.config. And you want to build the project again with your web.config, the build agent will delete the previous web.config and pull down your version. Then build the project with your's web.config.
Moreover, if both of you are not similar with TFS. Suggest you taking a look at below MSDN link which related to source control and build.
Use Team Foundation Version Control
TFS Vnext Build
We have some assemblies that are not referenced by our solution directly but are required for other libraries we are using.
I noticed in VS 2010 you can add a deployable assemblies folder and that would cause the files in it to get copied to the bin while building, it seems this was removed in 2012 as all of the Microsoft stuff is available in nuget now.
What is the best way to achieve this same effect, can I just add a folder to my project and add an after build copy task to copy all of that into the bin or is there a better way to go about this.
Currently the dlls are sitting in the project root and have their build action set to content which I gather makes them get copied to the bin, however I'd like to make it a bit simpler and not have to rely on having to set things as content.
What you're doing already isn't a terrible way of handling things, to be honest, and the way we've always done so here in my day job is simply to add the assemblies into our solution as references; that does mean that they pollute Intellisense, however.
Alternatively, Phil Haack blogged that you can create a folder called _bin_deployableAssemblies and put your files in there; Visual Studio 2010 will automagically copy those into your bin folder as a part of its default build action.
This doesn't work with TFS msbuild scripts, apparently, so The Dev Stop guys blogged about how to get that to work with TFS, using a customised Target in your msbuild script.
If _bin_deployableAssemblies is no longer working in Visual Studio 2012, I would guess you could add a build action to your project file, based on the TFS build action from The Dev Stop?
I have an issue. We are upgrading to VS 2012 at work. When we open a VS 2010 project Visual Studio converts the project. This is fine, because VS 2010 can still use the project (yay microsoft). However, there is a \Backup folder created in the solution directory. Is this being created as part of the migration? Is there any way to control it?
The reason I ask is that the process that makes this folder copies web.config files into the folder. If you then try to build the solution (these are MVC projects), we get a "It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS." error. The cause is that there is a web.config file in a subfolder instead of the root folder. We did not make and do not want this change, and cannot figure out how to control it. Deleting the Backup\Web.config file fixes the error. Renaming it from web.config to web.config.bak fixes the problem.
I don't really want to have to personally open and convert every single project, and don't want random people bumping into this problem. Any idea how to either stop VS from creating the Backup folder, or how to make it create them in the my documents studio folder etc? I can't find any setting to control this and can't find any good info.
By chance, are you using the MvcBuildViews property to pre-compile your views at build time? If so, this is why you're encountering this (since it does the pre-compile in the same directory, it doesn't filter out any of the files below the project directory).
Note that you will also encounter this issue if you use the Publish feature for this project. Publish copies the web.config under your intermediate build output directory (by default, obj/) before and after applying web.config transforms.
The good news is that in VS2012, or in VS2010 with the latest Azure SDK installed, pre-compile is now supported for Web Application Projects (including MVC). These settings are currently in the project properties, under the Package/Publish Web tab.
(this doesn't directly address your question about the Backup folder, but it was too long for a comment.)
There is no way to control it that I found. We had to go ahead and run through and convert every project to 2012 and delete the backup folders to prevent any other team from running into it.
I have two web projects, both these projects share client-side JavaScript currently residing as almost identical copies in both projects. I say almost because I'm clearly having versioning problems with these files.
I've managed to put the files in a solution folder and created links to them from my projects and this works when I publish the projects. However, when I run the WebDev server locally these files are not hard file system links? They seem to be maintained within the Visual Studio project as a reference only.
The problem is that the WebDev server will make a request to the presumable valid location of the file but it will not find it there because it doesn't exist as a physical file at that location.
Anyone know how to work around this?
If you use SVN, you could have the files managed as externals. Basically this will allow you to have the shared files maintained in one location, and have an external (physical file) reference to them.
http://svnbook.red-bean.com/en/1.0/ch07s03.html
Dave the Ninja
Here is a post that can help you :
Using Linked Files with Web Application Projects
http://consultingblogs.emc.com/jamesdawson/archive/2008/06/03/using-linked-files-with-web-application-projects.aspx