I have a very strange problem and my last hope for help I suspect comes from this community.
I have a build system that incorporates compiling three different elements of a wise installer package. The symptoms that I am seeing is that build times for these projects specifically degrade over time on the virtual machines. This is occurring on multiple virtual machines and has been doing so since November of 2013. Fortunately I had a habit of cloning the virtual machines and had a clone of the machine in early December where the symptoms were in the early stages.
For instance a normal build time should finish in 48 to 50 minutes. Times degraded slowly that by the time I noticed the problems times had degraded to 1hr 45min. I am not normally monitoring performance of the system but the results of the build - so I never knew. The cloned machine I had will restore the system so that it builds at 1hr 12 min approx.
Analyzing the build times, all of the time is being used by the wise installer. I have attempted uninstall and reinstalling the application. I have cleaned the temp directory, run chkdsk, and other normal debugging operations.
One of the wise installer projects is a merge module that requires recompile because it updates a database file. This should only take 8 minutes to compile. It takes over 1/2 hour.
Can anyone think of what I could look for to diagnose this problem? What could degrade the system so that in the course of a month the wise installer compile can loose up to 45 minutes on its build time?
Build Machine OS: XPsp3
HDD: SSD
Other builds do run on the same host machine and can run concurrently but previous to November 2013 this did not have an impact on performance.
If wise installer is causing the issue then you could try running procmon to see what is causing the hang. Windows performance recorder is another useful tool as explained recently by Alois Kraus - http://geekswithblogs.net/akraus1/archive/2014/04/30/156156.aspx
The problem is actually with our visual studio build.
For each build we increment the version number of binaries. We have a process that executes and updates the value in all proj files.
When visual studio compiles it adds assembly information to the registry for every .net file. Since the version number changed, the registry entry changes. The registry is never cleaned up. So I have just accumulated a year or more of registry entries.
When wise installer runs it is scanning through the registry, I am not certain why right now. Using ProcMon we can see the process running and reading the reg. Since the registry has bloated so much it slows down the build time.
Now the big question will be how to prevent this problem on a new build machine? How do I clean up all CLSID entries for our build?
On a pristine Win7 build system the entire build completes in under 20 min!
Also, I made one more change to the wise studio settings for the project. Instead of using high compression I switched it to mszip compression. Our output file is 50MB larger but the build time is far quicker - even on a new machine.
SOLUTION:
Add a clean solution task BEFORE changing the version number. This one change has resulted in a very consistent build time over several months.
The problem was that the company had changed the process of changing the assembly version and file version values. Little did we know that a rebuild was leaving assembly information in the registry on every build. So the task list now looks like:
Clean .NET solutions
Increment the version for file version and assembly version.
Build .NET solutions
Hopefully this helps anyone else who encounters the same problem.
Related
I use and love cygwin, but every few weeks it notifies me that a new installer is available and I should use it to get the latest bugfixes. But I find this quite annoying because of my company policy, where downloading, installing and running a new .EXE file is a bit of a process due to paranoid company monitoring software.
I am just curious why the installer updates so frequently and what will happen if I don't update it. It is after all just an installer - all it does is it downloads updated packages and installs them (or rather, that is what I believe all it is doing). I do not understand why such a simple tool should have so many fixes/updates over time. If I don't update the installer, will I miss out on updates to the cygwin packages themselves?
I have been using the same cygwin version since years now and not faced any issues.If the application is working as expected then you dont need an update unless you face some trouble or you are migrating to a new windows Os which might have some compatibility issues.
Note : There is no guarantee that there will not be any problems with applying updates and also the cygwin faq section says that after updates issues should be reported to the project or product supplier for remedial action.
https://cygwin.com/faq/
The changes in Setup are usually to improve the functionality or correct some
issue.
See relative Announce:
https://sourceware.org/pipermail/cygwin-announce/2021-April/010021.html
Most of the time, previous version continues to work fine.
Broke of compatibility is very rare.
So basically I haven't opened my Android Studio project for almost a year and this time was the time for it to be opened and built. After updating Android Studio and all of the project's plugins, I finally reach this error:
Execution failed for task ':app:processDebugResources'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
> Failed to transform play-services-base-17.1.0.aar (com.google.android.gms:play-services-base:17.1.0) to match attributes {artifactType=android-compiled-dependencies-resources, org.gradle.status=release}.
> Execution failed for AarResourcesCompilerTransform: C:\Users\Me\.gradle\caches\transforms-2\files-2.1\d92a27efcac738b4f280b9ad0c07bda7\jetified-play-services-base-17.1.0.
> AAPT2 aapt2-4.1.1-6503028-windows Daemon #0: Unexpected error during compile 'C:\Users\Me\.gradle\caches\transforms-2\files-2.1\d92a27efcac738b4f280b9ad0c07bda7\jetified-play-services-base-17.1.0\res\drawable-xhdpi-v4\common_google_signin_btn_text_dark_normal_background.9.png', attempting to stop daemon.
This should not happen under normal circumstances, please file an issue if it does.
I hope someone could help me resolve this issue. Thanks in advance.
update 07 May 2021
With Android Studio 4.2 and the corresponding android gradle plugin v4.2.0 (which requires gradle 6.7.1) the build now works for me also on my older AMD.
So I guess the problem has been fixed :)
(would be great if someone else can confirm via comment)
original answer
Hi have exactly the same issue.
The project builds on 2 of 3 tested PCs. The only difference I see is, that is not working on an older AMD processor. The PCs its working with have both Intel CPUs (an older i7, 2. Gen, and a new i7). All three PCs are running with Windows 10 Pro.
My dev environment is set up equally on all 3 PCs.
I hope this information helps to find a maybe better solution.
The only solution I found is to go back to a previous version of the Gradle plugin and Gradle itself.
In gradle-wrapper properties I defined Gradle version 6.1.1
distributionUrl=https://services.gradle.org/distributions/gradle-6.1.1-all.zip
And in the project build.gradle I set version 4.0.2
classpath 'com.android.tools.build:gradle:4.0.2'
Try:
Invalidate Cache / Restart
Clean Project
Rebuild Project
Along same lines: I too am getting this same error but oddly, my project is stored on OneDrive so I can access it/modify it from different locations. The SAME project builds, installs and runs with no issue at one location (with my phone connected to computer), but the error shown above takes place when accessing the same files from the other location (with the same phone connected).
The same version of Android Studio is being used at both locations as well. This was not an issue with this same project a few days ago (i.e. - it ran properly from both locations until recently)
The solution offered previously here does not fix the issue.
Would not normally put this response here but thought perhaps my experience with the same error message could help shed some light on what is happening.
the same topic is discussed here. I have the same behavior the same project builds without a problem on i7. But produces an error on an old AMD processor.
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)
Can you please advice how I can speed up a compiling, loading big solution (~50 projects).
I mean only VS 2012 studio or Windows settings, not hardware changes.
Thanks
Consider your need for 50 projects in one solution - having many projects that are referenced by each other is one of the main reasons for slowdowns.
One of the few valid reasons to have separate projects is because you need to deploy the generated assemblies separately. If this is not the case, consider combining projects - use folders for the logical separation.
The lower the number of projects, the faster your build will become.
In addition, if you change the builds to output to a specific shared directory and reference the DLLs instead of the projects, the number of unneeded re-compilations should go down drastically, though you will have to manage the build order yourself.
I use 100+ projects in a solution with Visual Studio 2012 Update 3, and it builds fast.
I agree with shared output directory comment by Oded, but I'd like to mention that project references work OK too.
Make sure that your \Users\\AppData\Local\Microsoft\WebsiteCache folder is empty. Somehow, this is a problem even with desktop-only solutions.
I have disabled Productivity Power Tools 2012, since they compile code in the background, a bit too much for my liking. Disable all plug-ins and extensions and see if it makes any difference.
Suppress excessive output messages to disk and to screen by reducing output verbosity
Use multicore with MSBuild.
As you code, try to limit dependencies between projects by using interfaces and abstract classes (C#).
Try fresh *.suo and fresh *.sdf files. (Make a backup of the user settings and DB, then remove them and try building again)
When all else fails, use ProcessMonitor or attach with another instance of Visual Studio to profile your Visual Studio while it's building.
Try excluding file system filters, such as antivirus, from your build. For example, some antiviruses have a way of skipping scanning in certain directories or by file names.
After upgrading to R# v6 I am unpleasantly surprised to see that the memory usage for the same application is using almost three (3) times what it did with v5.x, and is painfully slow. Not sure I would upgrade again if I had known this before hand.
Is this a known issue? Has anyone noticing the same jump been able to successfully tweak this?
Cheers,
Berryl
We're receiving mixed reports on memory and performance consumption in v6. In some cases, users call the new version a massive improvement over previous versions, other times they report increased memory consumption and lags in certain scenarios. This is pretty much the same story with every new version.
There are several known issues related to processing classic ASP files and in general processing source file on solution load. Both have been addressed lately and will be fixed in ReSharper 6.1 that is coming out later this Fall.
I suggest that you do the following:
Try to clean ReSharper caches by deleting YourSolutionName.suo and *_ReSharper.YourSolutionName* folder - this helps sometimes.
Downgrade to ReSharper 5.1.3 for the time being. This version is available via ReSharper archive.
As soon as ReSharper 6.1 comes out, install it to see if it's any better.
If it's no better, profile ReSharper and send the profile to us for investigation.
An alternative would be to profile 6.0 right away as there's a chance that your issue is something we've not yet investigated during 6.1 development.