What tool do you use to only zip up the source code of an open souce project or choose which files you want to include for packaging? I'm using Visual Studio 2008.
You can use a version control system like Subversion to do this. All the source files relevant to your project are checked in, and you can create a second working copy in another directory, check if it compiles (i.e. if the source is complete), clean it again, and zip it up minus the .svn directories.
In Visual Studio, use an add-on like AnkhSvn to make sure all files that are in your project are added to Subversion.
You can automate the svn update and zip with any kind of scripting language (msbuild, powershell, perl, python, etc...)
But then, you could also publish the Subversion repository url and let others use that instead of a .zip file!
Are you using a continuous integration process such as CruiseControl.NET? If so you can add a build step to zip up the entire working folder after a successful release build is done and any cleanup is performed, then even save it to an FTP somewhere if needed.
If not you could still do this in the build process from inside Visual Studio by editing the project file in the post build events. Both cases could be done using the MSBuild Community Tasks since there's a Zip task along with FTP and some others.
If you do an SVN Export instead of SVN Checkout, assuming you're using SVN, then the .svn folders won't be created so there shouldn't be any cleanup to perform before zipping up the folder since you'll have an exact copy of your trunk folder.
Ok, I have found 2 ways you can do this
http://www.codinghorror.com/blog/archives/000368.html
or
http://code.google.com/p/treetrim/
Related
We're using Visual Studio Team Services with Git as the source control system and I've configured a build which executes successfully online. Ideally I'd like to:
After building the site in VSO, precompile and dump the aspx and .dll files to the git repository
On the on-premises web server, pull from git and move to our staging site
The second part I can figure out on my own, but the documentation for VSTeam seems sketchy on how to dump the compiled sources to git. I've kept the default build configration almost the same as the default with the exception of a Powershell script which is supposed to create artifacts for the drop. Despite this, the drop.zip file create is empty.
The following is how my build definition is set up in VSO.
Instead of the PowerShell script, you'd be able to use the "Copy and Publish artefacts" and have it create a specific artefact with the specific bits you need:
This will automatically create a named build artefact which you can then use from Release Management as an input.
The PowerShell script was used in the XAML builds when used with the "Project Output | As Configured" option.
To create your "packaged" website, you need to add a couple of parameters to the MsBuild/Visual Studio Build step to instrict the compiler to package your website:
/p:DeployOnBuild=true /p:DeployTarget=Package
/p:SkipInvalidConfigurations=true /p:PackageAsSingleFile=false
/p:AspNetCompileMerge=true
Optionally you can configure your target directory as well using
/p:PackageLocation="$(Build.BinariesDirectory)\Published"
If you do this, you need to configure this directory as your copy root in the copy and publish task.
I did a quick look at the Power-Shell script, there are two issues with it:
It still use the variables like "$Env:TF_BUILD_SOURCESDIRECTORY" which does not exist in VSTS(VSO). See Variables for VSTS.
It copies the files from "BUILD_SOURCESDIRECTORY" folder to "BUILD_BINARIESDIRECTORY". But the "Publish Build Artifacts" step in your definition publish the files in "BUILD_ARTIFACTSTAGINGDIRECTORY" folder.
So if you want to use this script, you need to update the script to remove the "TF_" string in the variables and update the "Publish Build Artifacts" step to publish the files in "BUILD_BINARIESDIRECTORY" folder(Set Path to Publish to: $(Build.BinariesDirectory)).
However, if you want to copy and publish the website files, you can simply add one more argument in "MSBuild Arguments" section of "Visual Studio Build" step:
"/p:outdir=$(build.artifactstagingdirectory)"
Remove the Power-Shell script step and the other steps just keep default settings.
Or you can also change the settings of "Copy Files" steps to select the files/folders you'd like to copy.
I have a number of ASP.NET Web Form Websites (the one with no .csproj file), and I am trying to figure out how to best use NuGet packages with them. When using Visual Studio 2015, adding NuGet packages via the UI works correctly (there is a packages.config in the site root), and the build drops the binaries in the bin folder.
The problem is trying to build the project on TeamCity via MSBuild. For other projects, I can use NuGet.exe with the restore command (either against the csproj or the sln file), and the packages are correctly downloaded and included in the output. However, this doesn't work with the websites, and thus the compile fails due to missing files.
As a last resort, I could write a custom script/build step to manually copy the assemblies to the bin folder, but I'd like to avoid this. Am I missing something? Is there any way to use NuGet with websites outside of Visual Studio?
After some time, I have a workaround that gets me where I need to be, albeit not in the best way.
In newer versions of Visual Studio, when a binary dependency is added to a website via VS, it adds a (binaryfile).dll.refresh file to the bin folder alongside the binary file. The contents of the file is the relative path to the .dll via the packages folder for the solution. In addition, a packages.config file is added to the website.
The way to get it to build on a CI server is:
Ignore (.gitignore, .hgignore) the website's bin folder
Explicitly add the .refresh file(s) in the bin folder
Prior to the actual build, call NuGet restore, passing in the path to the website's packages.config and setting the PackagesDirectory (or SolutionDirectory) to the packages folder for the solution
Pre-Compile, MSBuild will open each refresh file, and copy the file from the location contained in the file.
It's not a great solution, because I now have to call NuGet restore multiple times (once for solution, once for each website), but it does work. I don't know how far back the .refresh file is supported, but it does work in 2015. I may make a change request in NuGet to allow for multiple solutions/packages.configs to be passed in via the command line.
Thanks,
Erick
I want to create a setup for an existent .exe file. This file needs some .ocx and .dll files to run correctly. So this mentioned setup should paste these all files in a specified path and then run the .exe file.
I have tried with installshield 2010 basic and InstallScript projects but i could not create some of dialogs in the format that i wanted.
Is there any way to create this setup? Or any one may help me to work with installshield?
You might find working with another setup program easier, try the NSIS (Nullsoft Scriptable Install System). It has a RegDLL function:
RegDLL "$WINDIR\OCX\vbalGrid6.ocx"
if you need that also.
We're in the middle of changing from VSS to Subversion and we have a website project on our Subversion Repo. We've removed the Bin folder as it causes all kinds of chaotic tree conflicts since our development solution contains some Class Library projects the Website project depends on (set up as project references in our solution). We also have a couple of 3rd party library DLLs in the Website's Bin folder too.
The next phase of our project involves a designer modifying themes to our website. I'd like for him to be able to just open the Website project in VS 2005, modify the CSS files he needs to on his working copy, and test his files on his localhost. He'll need the most up-to-date DLL files for him to be able to do this.
Is there anyway to add the Bin folder DLLs to subversion, and configure TortoiseSVN or subversion so that we can commit our newest DLLs (project dependencies in developer's solution files) but ignore them on update (per client I guess)? It would also be handy to have our 3rd party website dependencies on Subversion too.
You should not put 3rd-party assemblies into the bin folder. In fact, you should assume that the bin folder will be emptied before each build. It is a place to put the output from a build, not a place to put inputs.
Put these binaries in to some other folder, maybe "3rdPartyAssemblies". Use a file reference to these files, and they'll be copied into the bin folder, as outputs.
Would it not be possible to structure it like this:
Trunk/
WebApp/
ClassLibrary1/
ClassLibrary2/
ClassLibrary3/
3rdPartyDlls/
build.bat
The web app is what pulls all the class libraries and the 3rd party dlls in to the WebApp's Bin folder (All of these will be referenced via relative links). You can then setup TortoiseSvn to call the build.bat file on update through client side hooks. You would also setup IIS on the designer's machine to point to the WebApp directory.
As other users have pointed out, you could use svn externals to pull in those enterprise wide class libraries.
What most everybody else has said regarding '3rdParty' is correct.
You may also consider svn:externals to pull in related directories including a '3rdParty' assemblies directory, or even output directories from builds that can be triggered by a check in to assure currency.
The approach we've taken is, rather than having the Libraries in the same solution, they have separate solutions and we (well, our Build server) compiles them and checks the compiled DLLs into sourcecontrol under "Dependencies" which is always mapped to C:\Dependencies on all developers machines. We then use file references to this folder from the website project.
Thi way you can give your designer the Website project along with a copy of C:\Dependencies and they'll be none-the-wiser =)
We don't sourcecontrol the bin-folder since it would be updated everytime you run a compile. Instead, we keep references to 3rd part libs in a separete folder that is under version control, that we have references to in our project.
With this setup and using "copy local = true", they are automatically added into bin upon compilation.
Secondly, we will only commit new binary files when we update the 3rd-part binaries.
This approach is also possible to do for your internal dlls, so that your designer can just compile his visual-studio-solution so taht any relevant dlls would be put into his bin-folder and hence, create a functional site locally on his machine.
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.