How do you restore the code base to fresh installation? I am having some build/sync issues and I would like to undo all my code changes and start over.
Since you are asking for the easiest way: Deploy a new environment :)
Jokes aside, what I would do is to clean up the AOSService\PackagesLocalDirectory directory and delete the folders that contain your customizations. Alternatively you can copy the contents of the directory from a clean environment of the same version, in case you don't know the names of your customization packages anymore.
From Pradeep's comment: Then Open visual studio, Go to Model Management and Refresh model. Then do a full build and synchronize database.
This should restore your environment back to a clean installation.
Related
I've added a custom application to my installer project and use it as recovery tool if something went wrong during update or if the new application data contains any bugs.
So far so good, restoring files and database works, but I can't figure out how to restore the version number. How can I implement this?
You would have to restore the file .install4j/i4jparams.conf in the installation directory. It contains the version number, also the file .install4j/response.varfile if you query installer variables in your code.
Is there a way to create a "build" but not actually compile the output of the site? Bascially I want to push the files live from the source control in TFS to the final IIS folder destination.
I have used CopyDirectory on my other project builds, but that requires a BuildDetail.DropLocation (compiled Build). Maybe there is another option for the CopyDirectory Source I could use that wouldn't require a build DropLocation.
To simplify, I want to copy files directly from a tfs Source control to a folder, using a Build Template, but that won't compile the files. Is that possible?
While the default .xaml build workflow for Team Foundation Build is indeed a compilation build it does not have to be. I usually recommend teams to at least have one compile and one deploy .xaml workflow.
1) The CompileMyStuff.xaml (DefaultBuildTemplate.xaml) should take my stuff from source control and do whatever is needed to create a Build Drop folder with my output. I may or may not need to actually compile before creating the drop, and it looks like you just want to copy to the drop location.
2) The DeployMyStuff.xaml should take a build number and deploy my code to an environment of my choice.
It looks like you want to skip the "Drop" and go state to deploy and while I would never recommend this you do have a "BuildDetail.BuildLocation" for teh local workspace where the build server has done a get of your code. You can just "CopyDirectory" from there to your server/host for the website.
If you are having a little trouble you could use the Community Build Extensions and fire up PowerShell to do your copy/deploy.
I figured out a solution to this problem. I created a new .xaml file and then the only item that I put in the sequence was "DownLoadFiles". Then I filled out the properties of the task and ran a "build" and it worked.
I store all SSIS packages in Subversion repository, their configuration files as well. Configuration file almost always stored in the same folder where package is.
Problem is - SSIS seems to always store path to configuration file (the one saved in the package itself) as an absolute path.
When someone else checks out folder with the package in the location different from where I had on my development PC the configuration file is not detected (because my absolute path is stored and it doesn't exist on the other developer PC). So another developer has to remove this configuration and add it again from where it is now on his local hard drive. Then changed package is saved which will cause new version to be committed. When I get that version from SVN it will no longer match local path on my PC.
On a related note: another developer may want to change values in configuration file as well. If I later get the latest version of everything from SVN package will no longer work on my PC.
How do you work around these inconveniences?
Another solution is to save your configuration in a database with an environment variable as the first configuration to tell it what database to look in, that's what we do. We have scripts to populate ssisconfig for each server in our source control, but the package uses the actual table data for the database in the environment variable we are using.
Anyone who has heard my SQL Saturday presentations knows I don't much care for XML and this is one of the reasons. A trick to using XML configuration with varying locations is to use an environment variable (indirect configuration) to direct SSIS where it can look for that resource. The big, big downside to this approach is you'd generally need to create an environment variable for each set of configuration files or have a massive, honking .dtsconfig file which becomes painful for versioning.
The option I prefer if XML configuration is a must is that the "variableness" is removed. Developers and admins get together and everyone agrees "there will be a folder everywhere SSIS is done to hold configuration files and that location is X" and then it's just a matter of solving for X. At a previous job, we used D:\ssisdata\configs
#HLGEM's approach of a table for configurations is hands down my favorite approach to SSIS configuration (until you get to 2012 and their project deployment model where configuration is an entirely different animal)
I add a folder called "config" under my projects folder, add it to source control and mantain the config file in this folder. You can also add it to the SSIS project if you like.
I think its a good solution because everybody can have this folder and dowload the config file.
When the package is deployed it will read the config file from where you inform in the deployment manifest so this solution wont impact your development
We're using TFS and we're having problems when we switch branches, it's throwing up problems with the TFS bindings every single time.
We still have
.vspcc files
.vsscc files
which is I'm guessing where it stores the bindings, does anyone have any advice on how to easily switch between branches in TFS without pain?
These files are used to store files that are excluded from source control - and yes, they are themselves under source control. I've never had to worry about these before, so I don't think that's where the problem is.
Bindings are normally stored in your actual proj and sln files.
If you have problems with binding, you actually have some problem with your workspace. Either make a new workspace in a new local folder, and get everything from the server there from scratch (i.e. setting up the workspace mapping through visual studio, opening your solution via the source explorer etc. Don't use any clever tricks here - otherwise strange things happen), or try going to File -> Source Control -> Change Source Control, unbinding all projects and rebinding them. VS will blindly write the binding info anew into your project and sln files if you do this.
Especially make sure that all server paths you're checking out can be mapped to a local path.
Switching between branches is just done by opening the appropriate solution file from the appropriate folder/branch. It's not normal that this gives you problems, obviously.
I have my VCS set up to ignore "[project]/bin". Is this directory essential to restore a project, or can it safely be ignored?
The "bin" directory can be safely ignored. MonoDevelop will create it when building the project.
If MonoDevelop recreates the bin directory when you delete it, then this is simply a matter of taste, otherwise you have to leave it in. (Rails happens to give up if you delete its logs).
Putting empty directories under version control can make the build process more readily apparent to those who glance at the repository, but it can also clutter and distract if you'd rather see only the essentials.