21.8 bugs

Well, this bugfix version is even worse than the previous one.

1) Salesforce pull still does not work. 

2) resolving conflicts does not resolve them and the project get unuseable. you cannot pull, change and file stay stuck as out of date.

3) code coverage still does not work

4) Opening the pending changes causes the suite to crash

5) Test still take 30 min to load

6) Search in solution explorer stops working. Does not return results even the files are there

7) Code collapse stops working for no obvious reason

PLASE, .... just print out somewhere the exception. Salesforce by itself is depressing, and now it get even more depressing to work on SF with Welkin.

since the shell is build on WPF, have a look at this. https://wpfinspector.codeplex.com/

it will help you debug it.

also getting the error while trying to build

Hi ikljaic,

I'll just post here a part of the email that I've sent to you, so other users would also have this info.

To be honest – we’re confused at the moment with the last list of bugs you’ve reported. While we were aware of lots of issues in Pull process previously – after the latest hotfix our internal Salesforce development team have not reported any issues with pull and we were unable to get any of them under a good stress testing that we’ve done earlier last week. I also admit that some issues are also know (e.g. sometimes not working code outlining and Go to definition – it’s related to an Apex grammar that we have to build from scratch. Currently 2 team members are dedicated on fixing all the grammar issues and they’ve done a huge work in this direction).

Regarding tests taking so long – this is caused by Salesforce returning us empty symbol table in some rare cases. Because we’re unable to constantly reproduce this issue we’re right now changing logic for Apex Tests fetching. Currently it’s working in this way:

• Fetching info from Salesforce (this may take a lot of time)
  • if there’s an empty response from Salesforce we’re analyzing project content and taking tests from the project
  • if there’s not empty response it is cached (so the next time we’re not calling SF, we’re using cached data) and used by Tests runner.

After the next release this process would be like this:

• If there’s no cache - scan project contents for tests and display them, while giving user the ability to manually initiate data fetch from Salesforce.
  • If Salesforce returns not empty content – it’s cached
  • If Salesforce returns empty content – local data from the project is used
• If cache is available – it would be displayed to the user.

I think that this approach will help you with tests execution, but I still don’t think that it’s the best solution (there’s a lot of confusion about what data would be used) and we will work on this process more in the future.

However some issues that you’re reporting we haven’t noticed previously at all (like crashing Pending changes panel, not functional conflicts resolving) and some of them are related to the core Visual Studio functionality (Search in Solution Explorer) – which leads us to the situation when I’d want to ask you to provide us any additional info about your project, “tricky†moments in code (because of grammar issues I’ve mentioned before some “not-so-common†code blocks may lead to unpredicted behavior of outlining and go to definition), your activities with the project, what changes are done on SF side and what changes are done on your side when pull is not working and so on.