I have two solutions
SolutionA.sln
WebApplication1.csproj
SolutionB.sln
WebApplication1.csproj
WebApplication2.csproj
I also have two TFS 2010 build configurations
BuildConfigA
should build SolutionA and deploy WebApplication1
BuildConfigB
should build SolutionB and deploy WebApplication2 (but not
WebApplication1)
To prevent BuildConfigB from trying to deploy WebApplication1, I put a <DeployOnBuild>false</DeployOnBuild> in WebApplication1.csproj. But that also prevents BuildConfigA from deploying it. How could I accomodate this scenario?
This is what I ended up deciding to do. I now have three solutions
SolutionA.sln
WebApplication1.csproj
SolutionB.sln
WebApplication1.csproj
WebApplication2.csproj
SolutionC.sln
WebApplication2.csproj
I do most of my development in SolutionB because I like being able to easily reference and compile against both projects. I don't use SoluctionC at all other than as part of the following two build configurations
BuildConfigA
should build SolutionA and deploy WebApplication1
BuildConfigB
should build SolutionC and deploy WebApplication2 (and not
WebApplication1 of course)
Hmm I'm pretty sure a build configuration can also build+deploy single projects, not necessarily solutions. So you could also drop sln A and sln C, and point your builds directly to the csproj files.
Ohad
Related
I have a solution with multiple projects, 2 of which are the main projects. A .NET WinForms desktop app and an ASP.NET WebApi2.
I have defined a number of publish profiles in Server project, which currently I execute manually. Now, moving to an Azure build pipeline I have a couple of questions:
I create a new pipeline based on the ASP.NET template, which builds all the projects within the solution. Should I leave as is, or should I exclude the client-side projects. If yes, then how can I achieve this?
I'm used to Visual Studio building and publishing just afterwards. In a CI/CD scenario, I assume that the I need to separate the building and publishing/deploying. Is this correct?
It all depends, you may use the same pipeline do build WinForms to create a package/installer. It is all up to you. If you want to exclude you may do it creating configuration
Configuration Manager -> Active Solution Configuration -> New ...
and then you will define what project you want to build. Next you will use this configuration in your build to just compile project you want.
You may pass configuration here.
If you use YAML pipeline instead of classic you may consider using multi stage pipeline. Here you have documentation and here a simple tutorial. If you decide to have one pipeline please check deployment jobs for deploying your app, however this is not necessary.
You you secleted classic pipeline you should go with classic release pipelines.
What we use:
We use mercurial and bitbucket for repositories. Appveyor and kudu for continous integration and deployment. We are using visual studio 2015 as IDE.
What we have:
We have different web projects. They share some other projects. All of web projects have their own solution. Every solution have their own repository.
If there is change on develop branch. Appveyor builds this repository, tests and deploys it.
If there is change on default, kudu builds this repository and deploys it.
What we want:
We want to merge all of these projects in one solution. But I couldn't figure it out, how I can achive continous integration or deployment.
If I change something on webproject1, I just want to build and deploy webproject1. The other webprojects in solution neither should be built nor deployed.
Perhaps a single repository will help you. Using relative path to include the shared libraries from your different applications.
Each application can still have its own Solution file and your CI setup also stays as it is. What changes is that the shared projects you have across all applications will be referenced with relative path. E.g.:
Repository root\Core\Component1\Component1.csproj
Repository root\Core\Component2\Component2.csproj
Repository root\Applications\App1\App1.sln
Repository root\Applications\App1\Domain\Domain.csproj
Repository root\Applications\App1\Web\Web.csproj
Repository root\Applications\App2\App2.sln
Repository root\Applications\App2\Domain\Domain.csproj
Repository root\Applications\App2\Web\Web.csproj
Now your different application can include the Core\Components they need by adding existing project to solution using relative path.
Your continuous integration system will have VCS triggers watching the app and dependencies so only relevant changes fire a build.
So if App1 developer makes a change on Component1, and Component1 is also used by App2, the build server will trigger a build to App1 and App2, signaling any breaking changes. However if App2 doesn't not depend on Component1, then only App1 will build.
This is achieved by configuring the build triggers for your applications.
One benefit of this strategy vs having a single .sln is that you won't have to build everything each time you build solution (nor configure what projects to build each time you work on a different app)
Also note that you can achieve this with multiple repositories. But that means you'd need to check them out at the correct location so your relative paths work. It's also quite obscure since if you checkout App1 and try to build it. It simply won't work and you'll have to figure out which other repos to check out, etc.
You are using Mercurial but FYI, the way (one of) this would be handled with Git is with submodules.
So I have this pretty huge solution with many projects, few of them use dlls from other projects in this solution, some projects copy files to other directories after build is performed. (as post build events)
when I build the solution locally on my machine, everything is great and working, but when i configure a build, and build it on build server (we use TFS) something goes wrong and i get a an error when i try to load one of the applications in this solution. (the error does not give me much data on what went wrong)
so before i sit to debug all of this. does anybody know how can i smartly manage all the build actions that are performed locally and via build server and see the deltas?
I would like to be able to build the solution exactly the same on build server as i do on my machine (with directory structure, post build events..etc)
thanks a lot
The generally accepted way to do what you're after is to use NuGet for managing your assembly references. You can publish your dependent assemblies into NuGet as part of a continuous delivery process, then reference (and update!) those dependencies in the solutions that consume them as necessary.
This removes ambiguity ("What version of Foo.dll is Project X using?") and reduces runtime errors ("Why is Project X using Foo.dll 3.0? It was never tested with 3.0! It needs to run with 2.7!").
I have an app (ASP.NET 3.5/ VS 2010) that works with a database project.
Is there any downside to having the database project as one more project within the app solution?
Is it better to have another solution just for the database project?
No real downside in the scope of this single app. If the same DB is used by multiple apps, you might be more easily able to reuse it by having it in its own solution, but even then, you could set it up as an external in your source control and be able to reference the latest build from a "lib" directory downloaded when you update source on other solutions.
My rule of thumb is: if one project directly references another project, they should be in the same app solution. If the projects are related, but don't reference one another, they should be their own solutions, in separate subfolders of the same main folder. If two multi-project solutions are related, place them in separate places, then use Add Existing Project to reference the appropriate other project in the solution.
Most of my projects end up being solutions because I add a testing project. So I split up every component into a separate solution, and then reference the appropriate projects in other solutions as needed using Add Existing Project, so I can debug from one solution into another. But they are all kept separate and are stand-alone.
I am setting up a Continuous Integration server.
I have one issue that doesn't seem to be mentioned in the tutorials.
I have a ASP.net Web Application that I need to compile and them publish.
My Problem is that I seem to be able to compile the app but when I attempt to use a buildPublisher this copies every thing including .svn files & folders and ms CS files.
I am using an MSBuild task to compile my source. I tried setting my MSBuild Output Directory to directory but this didn't seem to have any effect.
What am I not understanding?
Thanks
You're probably looking for the _CopyWebApplication directive:
http://blogs.msdn.com/nmoreau/archive/2007/01/26/deploying-web-application-projects.aspx
We use CruiseControl.NET to deploy our ASP.NET applications to our test servers for the QA department so this is indeed possible.
In each project we created an additional build configuration called 'Deployer' which is identical to the Debug configuration with the exception of building an additional Web Deployment Project. So by running MSBuild in the Deployer configuration we can generate our compiled output in a known location.
We then use NAnt to perform a simple copy operation to the required location, i.e. into a folder where our IIS server is configured to look for the applications.
I know you don't mention NAnt in your question but it's well worth getting familiar with it if you want to get the most out of CCNet.
I'm not at work at the moment but if this makes any sense and you want some additional information then let me know and I'll pull some more information together.
Hope this helps
Are your bin or obj folders checked into svn? if so that would contribute or possibly cause this issue.
Because those folders shouldn't have any svn folders/files
You can configure SVN to call the .svn folders _svn instead.
Set the SVN_ASP_DOT_NET_HACK environment variable.