I am compiling a solution and want to not include some projects in the build.
I can manually go to the solution properties and unmark the build check box for those projects , but i am automating this , so is there a way in powershell i can set certain projects as not to build ?
Instead building the solution you can build only the projects from the solution you want to build. Building is not really related to PowerShell. I suppose you use .NET Core that build the solution file. dotnet build is able to build a single project. You can chain dotnet build commands to builds each individual project you want, and exclude some of them.
Related
I have 2 projects: A & B that I want to publish as NuGet Packages but I don't know how to develop efficiently in Visual Studio.
Solution 1
Project A
Project B - references Project A as NuGet reference
When I make a change to Project A that is needed in Project B do I have to publish Project A? Is there a way to get the project reference functionality during development? Maybe Project B shouldn't reference Project A via NuGet?
There must be a good way to handle this situation, no? I've reviewed the NuGet docs but I couldn't find anything. There must be docs/blogs/SO posts to read more about this... I'm struggling to come up w/ the right keywords.
You might want to look at this extension: NuGet Reference Switcher for Visual Studio 2017
This allows you to switch between NuGet packages and project references during development.
Check out this blog post: https://markheath.net/post/multiple-nuget-single-repo
Basically, dotnet pack handles this for you automatically. You use regular project references when developing.
There must be a good way to handle this situation, no?
The best solutions is that the project-to-project reference should be recommend when the referenced project is modified frequently, the nuget reference is more appropriate when share the reference project to others or publish it. Just like NuGet Reference Switcher doing.
For some more detailed info, you can check following thread:
nuget packages in local work
NuGet has many advantages as a package manager for the Microsoft
development platform, this does not mean that it is not flawed. Just
as you encountered, if the referenced project is modified frequently,
we have to rebuild it, build nuget, publish it for each modification.
That will bring a lot of boring work. To resolve this disadvantages,
the Project-to-project references should be a better way.
The
advantage of a project-to-project reference is that it creates a
dependency between the projects in the build system. The dependent
project will be built if it has changed since the last time the
referencing project was built. A file reference does not create a
build dependency, so it is possible to build the referencing project
without building the dependent project.
You could add following Post-build event command to pack your project after building.
"the nuget.exe path\nuget.exe" pack "project path\NuGetPackageLibrary.csproj" -OutputDirectory "Your target path"
When your build successful, the package in target path will be replaced by the latest version.
I have a solution that contains a number of projects. Some MVC Web Applications, Some Class Libraries and some Console Applications.
For the Web Applications we simply used Publish Profiles and created TFS Builds referring to those profiles for building deployment packages. We then used those to deploy the web apps.
How can I configure the Build Definition to give me the same results for my console applications?
The desired result here is to try and work towards automatic deployments using TFS and Release Management.
Update:
Ok, It seems I need to explain myself better.
We use TFS (MSBuild) to build the project. By simply "checking in" the code, it triggers our build which builds the project and creates a nice Website_Package.zip file in the drop folder.
What I am looking for, is for MSBuild to do the same for my Console Application. ie. I want it to produce a "ConsoleApp_Package.zip" file and dump it into my drop folder.
You can use the Zip task from MSBuild Extension Pack at http://msbuildextensionpack.codeplex.com/.
See http://www.msbuildextensionpack.com/help/4.0.8.0/index.html for an example.
You should just build, using MSBuild task, filling the Project with your console app .csproj and leave MSBuild Arguments empty.
Then you use a Copy Files task to get your files from bin folder to staging directory.
Example:
Source Folder: \bin\$(BuildConfiguration)
Contents: **
Target Folder: $(Build.ArtifactStagingDirectory)
After that you can add task to zip the files from staging directory.
We've recently added the excellent script# to our project. Currently we have it so that our VS build simply copies the compiled .js file from the output directory to the scripts directory of our web app.
We've decided to make it a permanent feature and so would like to make it so that the .js file gets generated as part of our web build NAnt script to ensure that it's always up to date. Is there any way to do this nicely or do I need to call MSBuild from my NAnt script specifying the .csproj file to run the compilation?
Thanks
Stu
This isn't likely the full answer (given I don't have experience with NAnt), but I'll offer it anyway, as it may help.
A script# csproj is very much like any other csproj relying on msbuild. If you've got some way to integrate other msbuild projects into your NAnt build script, the same model should ideally apply to script# projects as well.
In the version of script# that is in the github repository, a web project can add a reference to a script# project (thereby becoming dependent on the script# project), and include an msbuild deploy task, that will copy over scripts from the built script# project into the web project. You can see this in action in the Todo sample (https://github.com/nikhilk/scriptsharp/tree/cc/samples/Todo)
Using TeamCity 6.5, I am trying to figure out how to setup a manual deployment for a specific build run if it's possible.
What I would like to be able to do is to take an already built and tested TeamCity run (only the artifacts needs to be deployed - this is not a web application or site) and call an MSBuild step to publish the artifacts to somewhere else.
You can do what you want by setting up Artifact Dependency between the configurations where you want to do the manual deployment and the one where you have the built artifacts.
Once you have setup the Artifacts dependency, click on the Run custom build ellipsis near the "Run" button for the configuration. Here you will have the Artifacts dependencies part where it will say the configuration that this configuration you are running is dependent on and will also have a dropdown list from which you can choose the particular version of the other configuration from which to get the artifacts. Click run from here to run your custom build.
See here for more details: http://confluence.jetbrains.net/display/TCD65/Triggering+a+Custom+Build
You might be thinking about this a bit backwards. What you probably want is a build configuration that takes the previously known successful build (in TC terms it has a snapshot dependency) and then runs a different build targeted at dropping the artifacts somewhere. Pretty easily done by switching the output directories in MSBuild.
The most "integrated" way I could think to do it would be to add a dependency to your deployment configuration that depends on the latest pinned build for the dependent configuration. Then you just unpin any newer builds in the dependent configuration and pin the one you want and run the deploy...This is a bit kludgy and might not work very well if you depend on pinned builds for anything else in the dependent configuration.
The other built in way to do with would be to add an artifact dependency using a specific build number. The drawback of this method is that any time you want to deploy a different build, you will need to be able to edit the artifact dependency build number by hand and then hit run.
I have a bunch of Eclipse plugins and features, which I would like to build as part of a nightly (headless) build. I've managed to do this using a complicated setup involving manually specifying paths to Eclipse plugin jars, copying customTargets.xml, etc.
Is there really no simpler solution? Isn't there a way to just point out my Update Site's site.xml and say "build"; i.e. the equivalent of clicking "Build All" in the Update Site project?
Given that all the answers to this question are all 3-5 years old, I figure an update would be useful to others.
For those who want to add the building of Eclipse plugins to the CI process, I recommend they check out the Eclipse Tycho project. This is essentially a Maven plugin that allows you you to wrap eclipse projects within Maven project. With this we use Atlassian Bamboo to build our Eclipse plugin. This also allows us to use the Maven jarsigner plugin to sign our plugin files.
I've just been fighting with this problem myself. Are you using the productBuild script? Maybe putting your features into a product would help you out.
I am doing a headless build on a product configuration. The only script that I customized was to add some ant tasks to customTargets.xml to get my sources from SVN and to do a little cleanup on JNLP manifests after the build as I am using WebStart.
Then you only need to invoke antRunner on the out of the box productBuild.xml in the scripts/productBuild directory (in the pde-build plugin).
Check out Ant4Eclipse. I've used it to parse Eclipse's .classpath/.project files to determine project dependencies and classpaths. In combination with Groovy Ant Task, I have automatically built multiple projects in Ant using the Eclipse project files for build information.
A buildPlugin task exists, but I have not personally used it.
We are currently using PDE to automatically build features and our complete product. It works quite well. Make sure you use the right script for product build or feature build.
Eclipse Help on using PDE
EDIT: We've now migrated to Buckminster, which has an excellent command line interface.
You might look into buckminster and maven. There is a learning curve for sure, but they seem to do their jobs well.
We are using headlesseclipse, which can be found on Google Code:
http://code.google.com/p/headlesseclipse/
It works quite well, and can easily automate command-line building of plugins and features. However, I have not yet found a way to automate building of the update site via the command line.