Just installed the latest Umbraco (7.2.1) package via NuGet. My development environment is as follows:
Umbraco is installed installed on IIS8 as shown below and is all up and running.
My Visual studio project is set up as shown below (For the sake of clarity, any folder/file excluded from project is not in included in my source control.
The content folder houses all scripts, images & css
On build - bin, config, content, masterpages, usercontrols, Views, xslt, default.aspx, Global.asax & the transformed Web.config are copied to the IIS instance (I don't like running Umbraco in the same place as my project, it just seems messy.)
Is this an appropriate way of developing for Umbraco? Am I missing anything, my biggest concern is whether or not I should include the umbraco & umbraco_client folders in version control and in the post build action. Any suggestions would be great.
There is some debate over what should and shouldn't be in your repository and ultimately it comes down to personal preference. I used to only add custom files and files that I changed from the Umbraco install such as the config files however since the introduction of the Nuget package I do put all but the binaries into source control because when I upgrade via Nuget later on I can easily see changes and merge customisations back in.
It saves a lot of hassle running Umbraco directly (IMO) especially if you make any changes via the UI and if you're not running it directly then there is little point really in using the Nuget package because you will end up with a bunch of unused files in your project. In your situation you might as well keep your project clean and do a manual install into the location IIS is using for the site and only keep files in your project that you have created.
This is only my opinion so take from it what you wish but hopefully it is of some help.
Simon
Related
I am hoping for a little advice.
I am checking in my project (asp.net mvc 5) to source control (TFS) and when a fellow colleague tries to pull it down, most of the references are not being added to his project.
How can I insure that all the references to get added?
Generally, best practice is to use NuGet.
At least for packages that are not internal you must use NuGet. Let's say for EF, BundleTransformer & so on.
For that you must enable NuGet package restore and fetch all you need from NuGet Feed. More here: http://docs.nuget.org/consume/package-restore/msbuild-integrated
For internal dll's you can create an internal NuGet feed: https://docs.nuget.org/create/hosting-your-own-nuget-feeds and get packages from there or copy them in your project.
Don't forget to include the files into project if you copy them "by hand" and i think this is a good start.
There are other best practices like not referencing anything from GAC anymore and move all the dll's/dependencies/referencing to NuGet or to create a raw "Library/Vendor" folder in your project and copy all the necessary DLLs there (problem here is that you check in all the dll's to source control), but you will be sure that everyone will get exact the same version/reference & so on because the files are stored there (physically).
What are the references to?
There are a few different things to bear in mind:
References to other projects within the solution should just work, if they don't make sure that the referred to projects are building
References to things like nunit are best managed through nuget so you add them using it and then when your colleague checks out he only has to restore the nuget packages and it all works
References to things that aren't in nuget, you can either put them into nuget or I prefer to create a lib folder and put them into there. To get them actually checked in as dll's are normally excluded, add the folder and dll's and then use the source control explorer to find the folder, right click and choose "Add items to folder" and use that to add the dll's and files that you need. If you then reference the dll's in the lib folder they will be checked out and should resolve correctly for the other user.
I have my grunt file building the TS files and placing them in to the wwwroot folder. TFS/VS Keeps thinking that they are new files and adding them to the pending changes.
How do I make is so this is not happen. I only want the TS file in source control.
Update:
I have tried using .tfignore file
# Ignore all files in the wwwroot sub-folder
\wwwroot\
TL;DR
If you want to do front-end dev in Visual Studio 2015, don't use the ASP.NET 5 project template. Use the ASP.NET 4.5.2 Empty Web Project template. NPM, Bower, Gulp, Task Runner all work there too. Just add the appropriate config files through the New Item dialog (NPM Configuration File, Bower Configuration File, etc.).
Though ASP.NET 5 was released with Visual Studio, it is still very much beta. That doesn't only apply to the server-side features. The VS project type is also not ready for prime-time. The project properties are very limited in the UI. You can't choose to exclude items from the project. package.config exclusions don't appear to affect anything. VS doesn't behave with TFS on these projects and performs a TFS ADD on any generated file. This means that if I don't manually fiddle with TFS changes, eventually gulp builds will fail because it will want to make changes which TFS will block (e.g. delete when there is already a pending change).
All in all, the ASP.NET 5 project type is not full baked just yet. Fortunately, the only thing it really provides over the 4.5.2 project (that I've noticed) for the front-end developer is the Dependencies node in the project tree. That has some utility, but is not worth the cost currently. Instead, I installed the Visual Studio Command Line extension, which makes it convenient to run bower and npm commands as needed. I had to do this anyway for tsd (TypeScript definitions) since it doesn't have a GUI, intellisense, or bindings for its config file.
Add a .tfignore file. Details here: https://msdn.microsoft.com/en-us/library/ms245454.aspx#tfignore
You are using a Web Site project type and not Web Application.
Web site is only provided for legacy support and does not support features added to visual studio after... Well.. For a very long time > 5 years. Web site projects are inherently greedy with files and this is by design and can't be changed.
You should upgrade your project to a web application by creating a blank web application and doing the core files into your website and then opening it in vs. You will see that it has no files and you need to manually tell it which files to load.
This was a bug in the asp.net core tooling/TFS souce control interaction and has been fixed in VS 2015 Update 3, where the .tfignore file instructions should now be honoured:
https://github.com/aspnet/Tooling/issues/18
At my work we are just starting to use TFS with our team of 4 developers, and are at the same time transitioning from single developer projects to team projects. We are mostly using the default settings in TFS
I was the first to push up a simple Silverlight MVVM project consisting of a solution with a Silverlight and a web project.
When my team-mate pulled down my code and tried to compile, he was faced with many missing references (.dlls), Expression blend SDK, Ria Services toolkit, Telerik controls, simple mvvm toolkit, silverlight toolkit, etc.
What do we need to do, to add projects to TFS that have everything needed to be compile it when the next developer pulls it down?
There isn't a really good way to do this all automatically. What you'd generally do this this:
in your branch create a bin folder next to your src folder.
in the bin folder create folders for each component you're relying on
in each folder place the setup or a link to the setup
in each folder place the binary files you're using in your solution
in each folder place a readme with any manual steps that must be completed
if wanted you can create a powershell script or batch file which installs all required components. It isn't too hard to detect whether or not an application is already installed using powershell and wmi
Now you'll have to fix a few things in your solution:
make sure your references don't point to the GAC, but that they point to the assemblies inside the bin folder of your branch
make sure all the paths are relative to the solution. Any c:... paths will not carry over from one system to another
I found that the easiest way to do this is to unload the project in Visual Studio and then edit it. You can then quickly add hintpath="..\..\..\bin\component attributes to each reference. There are a few blog on this subject which provide different solutions which all solve this same issue.
This setup allows you to at least get the latest version of any solution and build it without having to install any tools. If some of your components rely on visual studio add-ins, then the designers for these tools usually won't work, but at least you're able to build them.
An often used alternative is to create a Virtual Machine base image for your project and install all the required components onto it. Then copy the image to each developers workstation and sysprep it to ensure they all have a unique name and identifiers. When the project needs to update its dependencies, let one developer create a new clean machine and re-distribute that to all team members.
If you're using Windows Server Virtualization or VMWare, it's quite easy to create differencing disks and allow developers to access these images remotely.
Another approach would be to use NuGet and script NuGet using a powershell script for your solution. This will work for most cases, but products like Expression Blend still need to be installed separately.
I've got a solution with Silverlight projects, a couple Web applications and some Windows service and their small Winforms test applications.
When I build it using TFS it puts all binary files in the Binaries folder. It also creates a _PublishedWebsites folder where it puts the web applications ready for deployment.
What I would like is for a few of the projects to have their ouput in a separate directory in the Binaries folder. I want the files that I would normally find in the bin\Release folder to be there.
I looked long and hard and could only find scarce documentation on how to achieve that and only for TFS 2008. There's a good article there link text and another entry for VS 2010 there link text. However, none of these work :-(
It seems that the build ignores the <OutputPath> property. I tried fiddling with the <AfterBuild> property but unfortunately if I use the $(OutDir) property I get ALL the files in the Binaries directory and not only the ones that just got compiled.
At the moment I'm setting up a separate build that only has the projects I'm interested in that get compiled but I would really like to have all the files needed for the release built all at once.
EDIT: I didn't make it clear enough but I'm using the latest version of TFS (TFS 2010 RTM). I set up <OutputPathDir> on the project level as explained in the links that I provided.
Cheers.
In your build definition (.proj) file, check that
<Project>
<PropertyGroup>
<CustomizableOutDir>true</CustomizableOutDir>
</PropertyGroup>
</Project>
Also, you may run into some problems if you're trying to compile what was once a "website" project type (created from File->New->Website->ASP.NET Webiste). They seem to override the output directory every time. We had to convert some of those to class libraries instead.
I'm a Fossil (and CVS configuration) novice attempting to create and manage a set of distributed Fossil repositories for a Delphi project.
I have the following directory tree on my development machine:
Projects
Some Project
Delphi Components
LookupListView
Some Client
Some Project For Client
Some Other Project For Client
Source Code
Project Resources
Project Database
I am setting up Fossil version control in order to version and share Projects\Some Client\Some Other Project For Client\Source Code, which contains Delphi 2010 source for a database project.
This project makes use of Projects\Delphi Components\LookupListView which is a Delphi component. I need this code to be included in the versioning system for my project. I will, in theory, need to include it in other Fossil repositories in the future, as well.
If I create my Fossil repository at the Source Code or Some Other Project For Client level, I cannot add any code above that level to my repository. What is the proper way to deal with this? The two solutions that occur to me are
1) Creating a separate repository for LookupListView and make sure that everyone who uses a repository for a project that references it "knows" that they must also get the current version of this project as well. This seems to defeat the purpose of being able to obtain a complete, current version of the project with a single checkout. The problem is magnified because there are other common component dependencies in this project.
2) Establishing my Fossil repository in the Projects directory, so I can check in files from various subfolders. This seems to me to involve an awful lot of extra path-typing when doing adds, and also to impose my directory structure (Some Client\Some Other Project For Client\Source) on the other users of the repository -- in this case, the actual client.
Any suggestions appreciated.
I use Git, but my approach can be applied in your situation.
I have one repository for all my components folder. This gives me an ability to get all of them with only few console commands (in case when I reinstall my OS or go to another computer etc.).
Also I have one repository per each of my projects. If some project uses 3rd party controls I create "components" sub-folder and do symbolic links (junctions) of every components set.
This approach have some disadvantages (when you "go back" in commits history of some project, components can be modified too. And if many projects are using same components this could cause some troubles). But I had no issues yet :)