There is a directory called gradle in my Android Studio project. They don't say it should be excluded from version control. What is in this directory?
Update #1.
Android Studio bug. It updates gradle/wrapper/gradle-wrapper.properties every time I run it.
The directory gradle having a Gradle Wrapper inside it
The wrapper is something you should check into version control. By distributing the wrapper with your project, anyone can work with it without needing to install Gradle beforehand.
Even better, users of the build are guaranteed to use the version of Gradle that the build was designed to work with. Of course, this is also great for continuous integration servers (i.e. servers that regularly build your project) as it requires no configuration on the server.
That is why it is not excluded from version control.
Related
I have a solution which I have a number of unloaded projects. When I build the solution locally the unloaded projects are obviously not built. In Configuration Manager, I can't even select configuration, platform, build and deploy options for the unloaded projects.
Now I have created an Azure Pipeline which also builds the solution. But the unloaded projects are still being built.
How can I exclude building projects in my pipeline?
Now I have created an Azure Pipeline which also builds the solution.
But the unloaded projects are still being built.
Both Azure Devops Pipeline and VS IDE would call msbuild.exe to build. When building a solution using msbuild, it actually is running command msbuild xx.sln /t:build ....
Check the content of xx.sln file (solution file) we can find it defines definitions about the projects within the solution. That's why if you build the solution, all these projects will be built. This is expected behavior when building whole solution. Sample .sln file:
And it's VS IDE's magic to exclude unloaded projects when building whole solution. The IDE will check the unloaded projects and skip them when building whole solution, it has advantage that the unloading project behavior in IDE won't modify your solution file. (It's important for solution under Git version control).
To sum up: It's expected that building solution will build all projects. When we unload the projects in VS, this action won't affect our source solution file or project file. VS will automatically skip the unloaded projects, which is the unique feature of IDE. (Unload is a UI action in VS, it has no effect on .sln/.xxproj file)
To exclude projects to build in Azure Devops:
1.Specify projects to build when building whole solution. (It doesn't change any file, so that it won't affect Version control)
You can check this answer and corresponding document. My devops task setting (no need to specify Build target):
2.Exclude projects from solution configuration (Not recommended) or create a new configuration that excludes specific projects (Recommended). The solution configuration is defined in solution file (sln), so this way would makes effect on Source control.
Exclude projects from solution configuration(Not recommended):
Create a new configuration that excludes specific projects:
Related document here. I suggest you can do the changes via VS IDE, and then push the commits to remote repo. It's complex if you're not familiar with msbuild and sln file, so I doesn't suggest doing that yourself. Let IDE do the job for you.
Once the remote repo get the changes:
We can build the solution in devops with customrelease configuration which excludes ProjectA and ProjectB instead of release configuration which contains all projects.
All these workarounds had been tested on my side before posting them.
Android Studio Version 3.1.3
Issue:
Gradle wants to re-download dependencies that were previously downloaded
For instance: "No cached version of com.android.support:appcompat-v7:27.1.1 available for offline mode."
It doesn't matter which version I use, it refuses to accept the ones located at "/~.gradle/caches/transforms-1/files-1.1/"
I have specified gradle service directory path (where the downloaded dependencies are) and ticked the "Offline work" option. I've tried using the default gradle distribution and a local gradle distribution "gradle-4.8.1-bin".
Am I missing something?
Does that mean that gradle only uses per-project cache? Do I have to download dependencies every time that I create a new project?
If so, is that a way to use the already downloaded dependencies?
Also, may I ask why does Android Studio has a tick option to "Work offline"? What is it used for?
I want to accomplish following flow:
All commits are built by AppVeyor and .nupkg is created with version for example 1.2.3-{build}.
When I decide code is stable enough, I want to manually deploy it to NuGet with version 1.2.3 (without build number suffix).
Then I change env variable from 1.2.3 to 1.2.4 and process is repeated.
I have almost complete AppVeyor configuration, but I encountered following problem:
AppVeyor tries to deploy every build to NuGet. I want to be able to manually pick which builds I will promote to stable and push them to NuGet.
How can I make AppVeyor not deploying any build without my action?
You probably need to use Environment instead of Inline deployment. Difference is described here
For your scenario you can simple remove deployment from build and create new NuGet deployment Environment to manually call is against specific build when needed.
I have been trying to find an "elegant" way to integrate non-NuGet package with my Bamboo builds.
There's a plethora of stacks on the topic of adding non-NuGet packages into NuGet bundles:
managing non-nuget dlls along with nuget packages
Creating NuGet package with reference to a non-NuGet reference
Trying to add non-.NET libraries to NuGet package
and the list goes on. There's also many a stack about using NuGet in Bamboo and that part works smoothly.
None of these deal with the situation of having an automated build environment, which may be sitting on some other remote server, running Bamboo.
Specifically, I'm trying to automate Xamarin.iOS deployments to HockeyApp.
The steps are:
Coding and local testing in VS2015 on Windows and with Mac for iPhoneSimulator
Merge into deployment branch and push to Bitbucket server
Bamboo picks up the push and kicks off build
Build checks out deployment branch
Runs NuGet downloads
Starts compile for Ad-Hoc/iPhone environment, creating IPA
Kicks off the HockeyApp deployment (there's a free addon for that)
Nearly all the steps are in place, except for the one where I have 2 dependencies which the commercial vendor (Syncfusion) has for unknown reasons decided to bundle into their "Studio" product, from where my Visual Studio project/solution has to refer to them by location outside of my project directory.
As a result, my Bamboo build fails with not-found DLLs, because they're missing as they would have to come in somewhere between 5. and 6. above.
I don't want to copy the binaries and then check/commit/push them into my repository, as that's considered a Bad Thing. My Bamboo Plan already successfully grabs NuGet packages before the actual build without having to drag binaries along.
Simply copying the DLLs on to the Bamboo build machine (i.e. where the remote agent is running) was one idea, but the problem is that the VS/MSBuild project file now has hard-wired directories - so, I'd have to install the whole Syncfusion Studio, or emulate their directory structure just for those 2 DLLs.
So I would need to adjust the .csproj references in an automated fashion. Not sure how I would do that, except with Yet Another Task and Script.
Apart from yelling at Syncfusion (which I've already done) about making all their DLLs available through NuGet (because some are, and those I'm successfully receiving in step 5. above), does anybody have a suggestion how to get this missing step to work?
For expediency sake, I have now added the libraries to the repository in a separate sub-directory.
It's not how I wanted to do it, but as the 2 libraries were a mere 200-300KB each and as there just didn't seem to be a simpler solution it solved the issue for now.
Specifically:
Leave .dll in .gitignore
Copy libraries you need into local sub-directory, e.g. LocalLibs/
add specific libraries with git add -f LocalLibs/speciallib.dll so that only these become a part of the repo
Change the project reference in Visual Studio to point to the local libraries, instead of their main install location
Verify that builds still work from within Visual Studio but also with MSBuild
I may revisit this and update if a better way comes along, especially if the libraries are significantly larger, such that you definitely would not want to add them to your repository.
Every time I publish the application in ClickOnce I get get it to update the revision number by one. Is there a way to get this change automatically to change the version number in AssemblyInfo.cs file (all our error reporting looks at the Assembly Version)?
We use Team Foundation Server Team Build and have added a block to the TFSBuild.proj's AfterCompile target to trigger the ClickOnce publish with our preferred version number:
<MSBuild Projects="$(SolutionRoot)\MyProject\Myproject.csproj"
Properties="PublishDir=$(OutDir)\myProjectPublish\;
ApplicationVersion=$(PublishApplicationVersion);
Configuration=$(Configuration);Platform=$(Platform)"
Targets="Publish" />
The PublishApplicationVersion variable is generated by a custom MSBuild task to use the TFS Changeset number, but you could use your own custom task or an existing solution to get the version number from the AssemblyInfo file.
This could theoretically be done in your project file (which is just an MSBuild script anyway), but I'd recommend against deploying from a developer machine.
I'm sure other continuous integration (CI) solutions can handle this similarly.
Edit: Sorry, got your question backwards. Going from the ClickOnce version number to the AssemblyInfo file should be doable. I'm sure the MSBuild Community Tasks (link above) have a task for updating the AssemblyInfo file, so you'd just need a custom task to pull the version number from the ClickOnce configuration XML.
However, you may also consider changing your error reporting to include the ClickOnce publish version too:
if (System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed)
{
Debug.WriteLine(System.Deployment.Application.ApplicationDeployment.
CurrentDeployment.CurrentVersion);
}
I implemented this recently using some custom tasks. An issue I found with implementing this with ClickOnce is that all your DLL files are updated. This causes the ClickOnce update to download all the application files every update. This bypasses on of the nice features of the ClickOnce deployment where only the modified files are re-downloaded in an update.
Just something to think about when implementing something like this with ClickOnce.
Steps:
Use external incrementing version number (if you leverage a continuous integration server like CruiseControl.NET, then it comes from the build label).
Use GlobalVersionInfo.cs (file link-referenced by all projects in your solution) to hold the current version and update it on the build with the AssemblyInfo task from the MSBuild Community tasks.
Script Mage command-line tool from the .NET SDK to update the ClickOnce manifest, using the same version (see the -v and -mv switches).
BTW, a nice bonus is that, whenever you automatically publish a newer ClickOnce deployment version via the integration script, if you also specify the minimal version to mage.exe (same as version), then every user will be updated automatically on the next application launch.
You'll probably need to create a piece of code that updates AssemblyInfo.cs according to the version number stored in the .csproj file. (The ClickOnce deploy version is stored inside an XML tag.)
You'd then change your .csproj file to run this bit of code when Publish|Release build is performed. The MSBuild folks have blogged about how to perform custom actions during certain build types; check the MSBuild team blog.