I've been looking around to see what support I can find relating to this but it seems non-existent for my particular issue.
As an example I started to uninstall jquery.datatables 1.10.10 from my project but after 30min it's still going.
The only obvious sign of whats going on is the progress bar seems to keep freezing in place for like 30 seconds before moving again.
Does anybody have any ideas what could be causing this or suggestions on how to diagnose this?
It seems it was due to team foundation which actions were also running slowly and once I dropped about half the projects I'd selected it made a major impact on both.
Additionally I'll be reviewing my Workspace mappings in case that had a knock on effect which others seem to indicate it can.
Related
I'm trying to start a dotnet MAUI app following the tutorial of MS in their official docs
I'm just opening the startup MAUI project(the built-in default one) and VS22 just won't have it. I get 40+ errors most of them about reference missing and duplication of classes/functions
glimps from the errors I get
now I have already seen a post here having somewhat of the same problem but the solutions(restarting and downloading workloads from the CLI using - dotnet workload intall) just didn't work for me.
I haven't done any changes to the code whatsoever so I really don't get what is the problem here.
any help would be appreciated.
Edit 1:
The app do seems to be working when I run the android simulator… which makes it even weirder
This is a bug in the tooling at the moment it seems. If you look at the errors, especially the ones in your screenshot you can see that these talk about Android. If you expand the Project column for a little you will see the list of target platforms that it's talking about.
Because everything is in 1 project now, it gives errors about platform-specific stuff because it is only looking at that one target that it's building. In this case, maybe you were building iOS and it gives errors about not being able to find Android types. This makes sense, however, we shouldn't see these errors in this case.
It's a bit hard to explain like this, I hope it makes any sense.
Long story short, it's a bug, it's being worked on. And you should be able to ignore them and it would still run as you've already discovered yourself. It gives a lot of noise however and if there is an actual error, you will have to find that in this list and fix that.
For almost every page I open in Firefox, I see this error in the Console of the developer tool bar:
(!) The Components object is deprecated. It will soon be removed.
The source is the html page. It happens with pages I create, but also on many common websites.
I found this documentation on Components object on MDN web docs, but that does not clarify a lot. Note that even that page shows this message(!)
It looks like a warning, but according to the Console filter, it is an error.
My main questions are:
Is this something for me, as a developer of the page reporting this, to solve?
If so, how do I go about that?
I am not aware of any problems as a result of this. For now, that is.
I have seen this for over a year, maybe longer. I mostly ignore this, but every now and then it starts nagging me again. I don't want my code to break suddenly and would like to get rid of this message obscuring other messages.
This is not for the developer of the page to solve.
While biking back home, a possible cause popped up in my mind: could one of the add-ons I use cause this and yes, that appears to be the case.
I restarted with disabled add-ons and the message was gone.
Then I enabled them one at a time and the culprit is
Selenium IDE.
A bug report on this issue was closed with Won't fix, with the message:
This error will resolve itself when we move to a native app later this year.
In a MozillaZine topic of 2012, it is explained how it could have been solved.
The first one is just a warning that the addon is using "Components"
directly, which won't necessarily always be possible when using the
Add-on SDK. (The preferred way to do it is to access the aliases for
Components.classes and Components.interfaces and such that the SDK
provides by requiring the "chrome" module.) It shouldn't be a problem
right now, but might become one in the future.
it happened for me after installing Selenium plugin in my FireFox.
I deleted the derived data and my frameworks are now messed up. Even though I removed and reinstalled the pod, xcworkspace simply refuses to detect it, worse it no longer creates the links and now it's all in red.
Really at a loss here.
Sorry if this seems like a stupid question but I'm self taught.
Latest update: I managed to get the app running again by changing "Build Active Architecture Only" from NO to YES. Not sure if this is the right way to do things but it works for me.
Still the frameworks are in red and I am worried Apple will not accept this project for it's store.
Anyone can help me with fixing it?
Progress # Day 2
This might be hard to diagnose without seeing the project, but Xcode keeps adding tons of warnings to my storyboard. It is a source controlled project, and if a team member cleans up all the warnings, pushes, and I pull, the warnings go away but as soon as I open storyboard, they reappear and they do not go away when I do the standard Update Frames option.
A lot of them seem to have to do with Stackviews, but I'm just confused why my coworkers can get the warnings to disappear and I cannot.
Has anyone experienced anything like this, or have any tips on how to approach solving this?
I was using Xcode 7.3 but after updating to 7.3.1 the problem still persists. Running OS X 10.11.6
Edit: Just to add some specifics, when I look at the source code versus my local code, it basically adds a ton of "Misplaced" tags, and a lot of values are changed by 0.5 or 1 pixel.
I do have the exact same issue when working with others on the same storyboard. It will happen every time you open (or another colleague) the storyboard. Here are some advises to avoid this :
When I open the storyboard, I know it will provoke this warnings. So if I don't add anything, before pushing a new commit, I reset any changes on the storyboard
I've come up with another good solution : using storyboard references as much as I can. So what I do is basically creating a storyboard for every flows (sometimes you can even have one storyboard for one controller). That way, when I work on a part of a project, it won't generate warnings on the totality of the storyboard. It avoids epic merge with many conflicts, it is easier to maintain, and it's faster to work on a small storyboard than on a huge one (Xcode is powerful, but when you have big storyboard, at a certain point it will lag).
But to answer to your question, I think everyone have that same issue when working on big projects, hopefuly apple will solve that one day, but for the moment you have to set good practices with your team. This is the only way to avoid wasting time at every pull ;) (at least for me, maybe someone has a better solution).
We are working in a CI environment, with Enterprise Cruise running our builds. Developers all have CCTray installed locally to notify us if a build breaks.
CCTray has a menu option Volunteer to fix build that you can use to let your team know that you are fixing the build. However this doesn't work in our environment (reasons: Fix build not currently supported on projects monitored via HTTP).
So the question is - does anyone have a technique that they use in their team that allows someone to indicate that they are fixing a broken build?
For me, Continuous Integration is not only about tools, but also about practices. One of them is the responsibility. In others words, the one who breaks the build is also the one who will fix it!
Shooting "I take it guys" is my prefered. ( in addition of the responsability romaintaz describe )
We send an email to the Developer's mailing list to let everyone know you are taking ownership of the build break.
We're co-located, we all run cctray, and when the build breaks we have an audio alert (red alert from the Starship Enterprise). When it breaks we all shout "who broke the build"! Once we figure out who broke the build we harhass them until they tuck their tail between there legs, do that stupid embarassed laugh, and volunteer to fix the build.
It's worth noting that things that aren't monitored by the build and tests can change on a CI box. For example: maybe someone went onto the box and changed a permission. Then when the next checkin is made it looks like the person that made the checkin broke the build when really it was the person that made the manual change without telling anyone.
On the volunteer thing, tools can help but verbal face to face communication is still king.
The onus is usually on who broke the build with their checkin. That's often obvious, even with multiple checkins from different individuals. After that there's a bit of negotiation if the build remains broken. Not particularly scientific or rigorous, but it seems to work.
If the build brokes, then in CCtray there is an option for "Volunteer to fix the build".
And it tells automatically to all the developers who is fixing the build