Just starting to use GIT for versioning Umbraco projects. Using VS2013 on W7. As the Team Explorer doesn't respect gitignore files I'm using Git Gui outside of VS.
The issue I have is that when I clone the remote repo on another machine and try to run the site, VS downloads and builds all the missing packages. Then starts up the site. I get a YSOD saying "Could not load file or assembly 'Imazen.SlimResponse' or one if it's dependencies".
Now I'm not sure whether that's a Slimsy issue or my gitignore file was wrong on the initial commit. I've used a combination of the visualstudio.gitignore and the Umbraco gitignore from GitHub. (My repos are on unfuddle btw). Below is my full gitignore file. I'd appreciate it if anyone can advise what might be wrong.
## Ignore Visual Studio temporary files, build results, and
## files generated by popular Visual Studio add-ons.
# User-specific files
*.suo
*.user
*.userosscache
*.sln.docstates
# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
build/
bld/
[Bb]in/
# Additional line to allow inclusion of 3rd party Dll's in bin folders
[Bb]in/*
[Oo]bj/
# Roslyn cache directories
*.ide/
# MSTest test Results
[Tt]est[Rr]esult*/
[Bb]uild[Ll]og.*
#NUNIT
*.VisualState.xml
TestResult.xml
# Build Results of an ATL Project
[Dd]ebugPS/
[Rr]eleasePS/
dlldata.c
*_i.c
*_p.c
*_i.h
*.ilk
*.meta
*.obj
*.pch
*.pdb
*.pgc
*.pgd
*.rsp
*.sbr
*.tlb
*.tli
*.tlh
*.tmp
*.tmp_proj
*.log
*.vspscc
*.vssscc
.builds
*.pidb
*.svclog
*.scc
# Chutzpah Test files
_Chutzpah*
# Visual C++ cache files
ipch/
*.aps
*.ncb
*.opensdf
*.sdf
*.cachefile
# Visual Studio profiler
*.psess
*.vsp
*.vspx
# TFS 2012 Local Workspace
$tf/
# Guidance Automation Toolkit
*.gpState
# ReSharper is a .NET coding add-in
_ReSharper*/
*.[Rr]e[Ss]harper
*.DotSettings.user
# JustCode is a .NET coding addin-in
.JustCode
# TeamCity is a build add-in
_TeamCity*
# DotCover is a Code Coverage Tool
*.dotCover
# NCrunch
_NCrunch_*
.*crunch*.local.xml
# MightyMoose
*.mm.*
AutoTest.Net/
# Web workbench (sass)
.sass-cache/
# Installshield output folder
[Ee]xpress/
# DocProject is a documentation generator add-in
DocProject/buildhelp/
DocProject/Help/*.HxT
DocProject/Help/*.HxC
DocProject/Help/*.hhc
DocProject/Help/*.hhk
DocProject/Help/*.hhp
DocProject/Help/Html2
DocProject/Help/html
# Click-Once directory
publish/
# Publish Web Output
*.[Pp]ublish.xml
*.azurePubxml
# TODO: Comment the next line if you want to checkin your web deploy settings
# but database connection strings (with potential passwords) will be unencrypted
*.pubxml
*.publishproj
# NuGet Packages
*.nupkg
# The packages folder can be ignored because of Package Restore
**/packages/*
# except build/, which is used as an MSBuild target.
!**/packages/build/
# If using the old MSBuild-Integrated Package Restore, uncomment this:
#!**/packages/repositories.config
# Windows Azure Build Output
csx/
*.build.csdef
# Windows Store app package directory
AppPackages/
# Others
sql/
*.Cache
ClientBin/
[Ss]tyle[Cc]op.*
~$*
*~
*.dbmdl
*.dbproj.schemaview
*.pfx
*.publishsettings
node_modules/
# RIA/Silverlight projects
Generated_Code/
# Backup & report files from converting an old project file
# to a newer Visual Studio version. Backup files are not needed,
# because we have git ;-)
_UpgradeReport_Files/
Backup*/
UpgradeLog*.XML
UpgradeLog*.htm
# SQL Server files
*.mdf
*.ldf
# Business Intelligence projects
*.rdl.data
*.bim.layout
*.bim_*.settings
# Microsoft Fakes
FakesAssemblies/
# Note: Specifically for Umbraco
# Ignore unimportant folders generated by Umbraco
**/App_Data/ClientDependency/
**/App_Data/ExamineIndexes/
**/App_Data/Logs/
**/App_Data/[Pp]review/
**/App_Data/TEMP/
Cached/
# Ignore Umbraco content cache file
**/App_Data/umbraco.config
# Don't ignore Umbraco packages (VisualStudio.gitignore mistakes this for a NuGet packages folder)
# Make sure to include details from VisualStudio.gitignore BEFORE this
!**/App_Data/[Pp]ackages/
!**/[Uu]mbraco/[Dd]eveloper/[Pp]ackages
As far as I recall, I just installed Slimsy from the Umbraco Development section in the site.
I don't know if package restore downloaded it again as it was doing a ton of stuff all at once. The solution re-built itself when I did a right click on default.aspx and hit "View in Browser". I didn't build it on purpose.
I think I'll delete it and clone it again (for the 3rd time), take better notes and report back ;) it would be good to know if there really is a problem putting some packages in GIT and what the best gitignore set up would be, if there is such a thing as a "best" one the context of anyone adding any package (nuget or umbraco), that is.
Ok, so found Imazen.SlimResponse was a NuGet package so installed it. Rebuilt solution and now I get an error about missing namespace "Slimsy". At least it will now run the Umbraco back-end, so republished entire site but ended up with the same error. Deleted Temp dir contents, rinsed and repeated, same error.
Just so you understand this:
You've ignored your bin folder, so anything that gets put in thare will not make it to the next environment where you do a git checkout (it was never committed). So you have to make sure that anything in there is either a NuGet package (which restores files automatically) or you commit it into a lib folder and reference it in your solution so that it will get copied in at build time.
So to fix this you should compare your bin folder on the working machine to the bin folder on the other machine, you'll probably see some files missing (like Slimsy).
Indeed. I just noticed that none of the Umbraco packages installed in the live site are installed in the cloned site.
So it seems it's best NOT to blindly follow the advice in the GitHub:Umbraco gitignore file: "# Make sure to include details from VisualStudio.gitignore BEFORE this" and assume that means the unadulterated VisualStudio.gitignore file.
Basically I'm trying to develop a sensible gitignore file creation strategy. So I think what's needed is to commit the /bin/ folder and ignore any /bin/projectname.dll(.pdb) files individually, as they'd be built by the cloned environment.
I'm guessing the /bin/projectname.dll.config file would have to be committed.
The advise make a LOT of sense, you just have to get used to a new way of working. Do NOT commit the bin folder.
You should make a /lib folder in the root of your project and copy files in there that absolutely can't be installed through NuGet. As I said, add those files as a reference and they will be copied in on build. The rest you leave to be handled by NuGet package restore.
I don't have time to explain in depth but the most important thing you should know about git (or any source control really) is that committing binaries should be avoided at all costs. You should do some Googling to get into the reasonings behind this. Then you can still make the decision to include the git folder, at your own perril. ;-)
I've been doing nothing but reading up and experimenting with GIT for the last 3 days solid, i.e. haven't been out of the house.
If the virgin Umbraco installed /bin/dll's aren't committed then how do they arrive in the cloned environment? I understand if you happen to have installed Umbraco via NuGet then the package manager "might" do it, I'm not sure, I don't work for the HQ ;). But if you installed it from a zip file or just copied a previous install, then you'd be stuffed surely?
By the way, I'm having none of these problems with non-umbraco projects. i.e. projects where the bin folder contains a few dll's built BY the project (which I don't commit) and just maybe one or two 3rd party dll's (which I do). So as far as I'm concerned it's an Umbraco/Nuget/Package best practice issue that I'm trying to get to the bottom of. And, hoping others may be interested in too (otherwise I'd just ask these questions on StackOverflow).
The topic is a bit old, but I give it a shot.
We start to migrate from TFS to git and I have a question about the git ignore file.
Do we want to ignore the /umbraco and the /umbraco_client folder?
Our buildserver restore's these folders with Nuget. So can i safely ignore these folders?
For some folders we need to make an exception as we want those in source control, you can think of a folder like /umbraco/plugins. Not all packages have nuget packages so we add those to source control.
You'll need to include umbraco/plugins probably and then whenever something doesn't work as expected include that as well. Our old guidance was to dump all plugin related files in the Umbraco folder which was obviously a bad idea for this very reason.. :-)
Git ignore or Slimsy Issue
Just starting to use GIT for versioning Umbraco projects. Using VS2013 on W7. As the Team Explorer doesn't respect gitignore files I'm using Git Gui outside of VS.
The issue I have is that when I clone the remote repo on another machine and try to run the site, VS downloads and builds all the missing packages. Then starts up the site. I get a YSOD saying "Could not load file or assembly 'Imazen.SlimResponse' or one if it's dependencies".
Now I'm not sure whether that's a Slimsy issue or my gitignore file was wrong on the initial commit. I've used a combination of the visualstudio.gitignore and the Umbraco gitignore from GitHub. (My repos are on unfuddle btw). Below is my full gitignore file. I'd appreciate it if anyone can advise what might be wrong.
Cheers,
Craig
Did you install
Imazen.SlimResponse
as a NuGet package? And did package restore download it again? If so, did you build the solution after that?As far as I recall, I just installed Slimsy from the Umbraco Development section in the site. I don't know if package restore downloaded it again as it was doing a ton of stuff all at once. The solution re-built itself when I did a right click on default.aspx and hit "View in Browser". I didn't build it on purpose.
I think I'll delete it and clone it again (for the 3rd time), take better notes and report back ;) it would be good to know if there really is a problem putting some packages in GIT and what the best gitignore set up would be, if there is such a thing as a "best" one the context of anyone adding any package (nuget or umbraco), that is.
Ok, so found Imazen.SlimResponse was a NuGet package so installed it. Rebuilt solution and now I get an error about missing namespace "Slimsy". At least it will now run the Umbraco back-end, so republished entire site but ended up with the same error. Deleted Temp dir contents, rinsed and repeated, same error.
Just so you understand this:
You've ignored your bin folder, so anything that gets put in thare will not make it to the next environment where you do a git checkout (it was never committed). So you have to make sure that anything in there is either a NuGet package (which restores files automatically) or you commit it into a lib folder and reference it in your solution so that it will get copied in at build time.
So to fix this you should compare your bin folder on the working machine to the bin folder on the other machine, you'll probably see some files missing (like Slimsy).
Your .gitignore looks great by the way, this is what you want, try to stuff as little binary files in your repository as possible.
Indeed. I just noticed that none of the Umbraco packages installed in the live site are installed in the cloned site.
So it seems it's best NOT to blindly follow the advice in the GitHub:Umbraco gitignore file: "# Make sure to include details from VisualStudio.gitignore BEFORE this" and assume that means the unadulterated VisualStudio.gitignore file.
Basically I'm trying to develop a sensible gitignore file creation strategy. So I think what's needed is to commit the /bin/ folder and ignore any /bin/projectname.dll(.pdb) files individually, as they'd be built by the cloned environment. I'm guessing the /bin/projectname.dll.config file would have to be committed.
Would you agree?
:)
The advise make a LOT of sense, you just have to get used to a new way of working. Do NOT commit the bin folder.
You should make a /lib folder in the root of your project and copy files in there that absolutely can't be installed through NuGet. As I said, add those files as a reference and they will be copied in on build. The rest you leave to be handled by NuGet package restore.
I don't have time to explain in depth but the most important thing you should know about git (or any source control really) is that committing binaries should be avoided at all costs. You should do some Googling to get into the reasonings behind this. Then you can still make the decision to include the git folder, at your own perril. ;-)
I've been doing nothing but reading up and experimenting with GIT for the last 3 days solid, i.e. haven't been out of the house.
If the virgin Umbraco installed /bin/dll's aren't committed then how do they arrive in the cloned environment? I understand if you happen to have installed Umbraco via NuGet then the package manager "might" do it, I'm not sure, I don't work for the HQ ;). But if you installed it from a zip file or just copied a previous install, then you'd be stuffed surely?
By the way, I'm having none of these problems with non-umbraco projects. i.e. projects where the bin folder contains a few dll's built BY the project (which I don't commit) and just maybe one or two 3rd party dll's (which I do). So as far as I'm concerned it's an Umbraco/Nuget/Package best practice issue that I'm trying to get to the bottom of. And, hoping others may be interested in too (otherwise I'd just ask these questions on StackOverflow).
When you have time, you might like to read the comments on this discussion ;) https://robinwinslow.co.uk/2013/06/11/dont-ever-commit-binary-files-to-git/
The topic is a bit old, but I give it a shot. We start to migrate from TFS to git and I have a question about the git ignore file.
Do we want to ignore the /umbraco and the /umbraco_client folder? Our buildserver restore's these folders with Nuget. So can i safely ignore these folders?
For some folders we need to make an exception as we want those in source control, you can think of a folder like /umbraco/plugins. Not all packages have nuget packages so we add those to source control.
You'll need to include umbraco/plugins probably and then whenever something doesn't work as expected include that as well. Our old guidance was to dump all plugin related files in the Umbraco folder which was obviously a bad idea for this very reason.. :-)
Hi Sebastiaan,
Then I will add these folders to the ignore file and track the /plugins folder.
Thanks!
is working on a reply...