I have recently had a few issues when checking out a colleagues ASP.NET project, that causes the Project to get into a conflicted state because of the WEBINFO file being checked into SVN.
Does this file need to be in the repository or should we exclude it?
Yes, I think .webinfo should be excluded. (Some info about webinfo: How to copy and configure ASP.NET projects between different local computers)
Related
I have always used the express versions of Visual Studio for my Asp.Net projects. In the past, I would use a basic FTP synchronizer to push updated files (*.vb) to our server, then the changes would just show up on the website instantly. Now, for some reason, when I make changes to our *.vb files, they are not being reflected on the server after I synchronize over ftp, unless I build the project first. In addition, for our .Net 4.0 project, VS 2015 14.0.23107 is adding the following directories, with tons of stuff inside of them:
/.vs
/My Project
/Obj
There are loads of files within these directories which I have no idea what they do, and for some reason our project has taken on a completely different behavior. Now when we try to synchronize over FTP, there are a ton more files, and it seems that changing the actual underlying source doesn't work. We have to synchronize all the other files in the above directories, then we can see the changes.
Is this a new way they are doing things, or is this because VS is now free and we are getting a better version where we have to "publish" not "synchronize?"
Is there a way to go back to the simple way of doing things, where we just have a plain directory with our source files and sync them over to the server? Should we not do it this way? If not, what method should we be using and what files should we be pushing to the server?
I'll just promote my comment to an answer. There are several aspects of this question:
Use publish, this feature is already for long available in Visual Studio and works well. There is plenty of ways to customize it and it supports a lot of technologies, including FTP. It's also more convenient, systematic and reliable way of deployment than manually copying files to your FTP. You can also share your publishing configuration among developers and store several of them. No loss here.
I don't quite get why would you like to copy the source (.vb) files to the server. What you would usually like to achieve is to get compiled DLL's + resources copied to your server, and source files 'secure' on developers machines. You can compile your sources on the server if you really need it, but then just plug it into a source control, use ms build etc. Anyway, build/publish actions are there to prepare the deployment files for you, manual copying is pure bad.
For the new folders:
Obj is everything but new, its created to store some resources, crap, more here: What is obj folder generated for?
.vs stores user specific settings, and you should ignore it as well as obj folder, more here:
Should I add the Visual Studio 2015 .vs folder to source control?
My Project is most likely your own folder, nothing related to VS.
To sum up, as long as you use asp 4, 4.5 nothing changes. Only the 5.0 intruduces a bit different rules for deployment. Most of the problems you get are easily solved using the right tools (Publish). It will know what files to ship (binaries + resources included in project) and what to ignore (source files, caches, crap). It's convenient, less error-prone and can do much more for you.
Definitely, use "Publish" option (right click on your web application at solution explorer, under Run/Build options), thus you can update your server site with those files created on Publish. As Mikus mentioned, you DON'T need vb files on your published site, you just need dll's and resources (images, js, css, resx, e.g.).
Regards, hope it helps.
Use the Publish Option which is provided by Visual Studio.
This will compile your project and you can then host this in your reliant manner.
I personally host on IIS and considering I have no data stored locally I can publish directly to the published path on the IIS Server.
The Publish tool is very simple and only takes a few minutes.
Background: Trying to set up my dev. environment in new job. Have subversion installed ok in Flash Builder 4, and checked out the project folders I will be working on. Work to date was developed in FB3, I'm going to be using FB4.
The folders/files that get imported to the project also include .flexProperties, .actionScriptProperties, .project, html-template etc (basically everything).
I would have thought that just the src, libs, lib-rsl etc should be part of the svn?
UPDATE:
Here is a good link to setup details for sharing svn flex projects using 2 folders, one of which has the checkout code, the other of which has folders linked to the first (but without the project/setup files)
It depends on the the development group. If everyone is provided the exact same set of tools in the exact same environments it can be ok to include the IDE project files. But if there is any chance that anyone is going to use a different environment (this includes a rolling upgrade of tools) then it is a bad idea. I recommend against putting these files in source control.
background:Me and my coworkers are working on asp.net mvc project ... we have a computer that works as a server which is where the project will be stored on... each of us has a copy of the project and we got tortoise cvs set up.
questions:
when you want to commit something, what files exactly do you commit?.. asp.net reports many dll files, csproj files, cs and sln files that appear to be different from the server's.
Maybe my question is not the right one I should ask so I would appreciate some insight on whats the best approach for working in groups.
The basic csproj file should be committed whenever you add or remove things from the project, to ensure that the project has all the correct files. The solution (sln) is a good one to commit, for the same reason, although I've also seen it done without. You'd also want to commit any cs files, naturally, as they're the main focus of things.
DLL files should only be committed if they're outside references--internal dlls to your project can be ignored, as they'll be built by each computer in turn. You also want to avoid .user files as unnecessary. Ignore the 'bin' and 'obj' folders for each directory, when it comes to commits as well.
You really shouldn't check in anything that the project can generate itself. So no need to check in your bin or obj folders or anything like that, you also want to ignore any user preferences files.
This includes dlls, unless they are third party dlls, then you want to check them in to ensure everyone is working against the same version and this way you don't have to keep changing reference paths.
I don't work in asp.net, so I will respond generically.
We have a subversion code repository for our version system, cvs works well too. Developers retrieve all updated code from the repository, do work, make sure it's working correctly, do another get, re-compile, test, and then commit source code changes to the repository. On a regular basis you can have a tool or manually build the application from the repository, and deploy to a testing server. No compiled code should be placed in the repository.
-Jay
We use the following project structure in SVN (but this applies to CVS as well).
+ tags
+ branches
> trunk
+ build (build scripts)
+ lib (external libraries)
> src (source code)
>> Organization.App (solution name)
>> Organization.App.Core (code library)
+ Config
> Domain
> Model
> Persistence
> Queries
> Services
> Persistence
> Services
>> Organization.App.Web (mvc web app)
> Assets
+ Images
+ Scripts
+ Stylesheets
+ Controllers
+ Views
+ ViewModels
We put all our 3rd party dependencies into the lib folder. Including MVC, which can be bin deployed. See this article by Phil Haack. So when a new developer comes online all they have to do it check out the trunk, and they should have everything they need to get going. Using a CI server is a cinch because all of the projects dependencies are encapsulated by the lib folder and all of the visual studio projects make reference to those dll's in that lib folder.
Does that make sense?
Never mind the core folder and the web folder. That's just how we structure our projects within the solution. But that's a whole other conversation. :)
We keep everything except the BIN/OBJ folders in SVN. We have all third party Libraries in a seperate folder that they are referenced from.
Kindness,
Dan
If you are using a database change management tool, such as Tarantino, then you will also want to check in SQL change scripts and/or populate scripts. We have a folder in our 'Core' solution where we keep these, ie 'Core/Database/Updates'. We use SQL Compare to find changes in our database then we check in those SQL change scripts so that other developers can just run them locally. We have a nant task setup to call on Tarantino to sync up the other build environments (Dev, QA) and run any new change scripts.
I've just started using Subversion with ASP.NET web applications via the VisualSVN IDE plugin. There are a bunch of files which Visual Studio automatically generates so I don't want to version control these since they're not really part of the codebase and not required to build.
Does anyone have a definitive list of the main files that should be ignored when commiting to Subversion from an ASP.NET Web Application? and how would I go about ignoring these files. If possible I'd like to set it globally so that I don't have to keep doing the same thing for every ASP.NET Web Application that I write and create a new repository for.
Answers
A list of files to ignore as submitted in the answers below,
bin
obj
*.exe
*.pdb
*.suo
_ReSharper.*
*.user
General concensus seems to be that these should be ignored on a per project basis at the creation of the repository. They will then be ignored by all users using the repository.
Not really 'definitive', but I always ignore .suo and .user files and the bin/ and obj/ directories
Here's my ignore list from TortoiseSVN. VisualSVN requires TortoiseSVN and uses its settings.
bin obj *.exe *.pdb *.suo _ReSharper.* *.user
I haven't committed any unwanted (or not committed any wanted) files with this setting.
If you have any WCF service references then you only need to include the files Reference.cs and Reference.svcmap for each service reference.
The AnkhSVN plugin for Visual Studio has a list of files to ignore automatically and will only commits the files needed.
At least that's how I find it. It's taken me a few attempts at setting up the repository correctly but with AnkhSVN only commits a subset of he files that TortoiseSVn wants to commit. If ignores files recompiled on every Build for example.
Depending on your situation, you might want to keep the Web.config out of revision control as well. Different developers might require different configuration files for a website.
I'd recommend setting up a separate directory in your repository with a reference configuration file for the website and ignoring *.config on the actual project directory.
Additionally, to cover case sensitivity issues with "bin", I had to add [Bb]in to mine. So I have:
[Bb]in obj *.exe *.pdb *.suo _ReSharper.* *.user
Also, this link explains how to handle project specific excludes as well so that others get the same exclusion behavior only for the same project when they check it out:
http://svnbook.red-bean.com/en/1.1/ch07s02.html
I used the svn:ignore property on a particular directory to exclude a certain set of files that were copied into there (but I still wanted the directory itself in svn).
Use VisualSVN to do the initial "Add files to repository" and it automagically ignores the stuff you don't want-such as suo files and the bin/obj folders.
Right now I'm working with an ASP.NET website that automatically generates images and stores them in a temporary folder. When working on my local system these go going into a temporary folder that gets picked up by Visual Source Safe which then wants to check them in. As such, I am wondering if there is a way to just exclude that particular folder from source control?
I've done a bit of reading and found that there are ways to do this for individual files, but I haven't found anything yet about an entire folder.
I think you've found one of the main reasons MS went back to projects in VS2008 and in MVC.
It's been a long time since I've used VSS (mainly because it's really out of date now), but most source providers let you exclude files and folders as a setting of the provider, rather than the project under control.
If you can switch to a Web Project rather than a WebSite then do so, otherwise I'd look at updating your source control provider, as this sort of exclusion is easy with Vault, CSV, SVN, Git, VSTS and so on (to name but a few).
Are you using ASP.NET Website or ASP.NET Web Project? The difference is significant enough to solve or promote this problem.
Websites, love to scan the file system and auto checkin.
Projects, checkin only what you tell them to.
Also Visual Source Safe is pretty out dated, most recent source control systems allow you to do what you are asking. SVN and TFS 2008 SP1 do from my experience.
You can also try to right click and pick "Exclude" on the folder, but in the case of a Website I believe this renames the folder.
I'm not sure if this is an option for you, but if you exclude your temporary folder from VSS (delete the folder inside VSS using the VSS UI), the files that go into it should not get "picked up" again.
If you perform operations on a parent project of the temporary folder, you may try cloaking the folder.
http://msdn.microsoft.com/en-us/library/x2398bf5(VS.80).aspx
I would suggest emptying/deleting your folder from your website. Have your website on startup create/verify the folder, and on shutdown to clean it up and remove anything in it. This can be DEBUG code only (wrap in #if DEBUG) if so needed. Also add a build script to your project that does this every time it is built also.
Could you just make your application write to a temporary folder that is outside of your website?
e.g. in C:\tempfiles
VSS shouldn't be able to pick it up then.