I was trying to create a sample project that could replicate some other behavior I am seeing, and I’ve run into a situation where my solution is throwing an error when building in VS2019 but it builds successfully in Water. (I thought maybe Water would then fix it for VS2019, but that does not seem to be true.)
I’ve attached the solution here. The error I’m getting in VS2019 is:
TypeMismatchExample.zip (584.7 KB)
This is 10.0.0.2604.
–Avonelle
Curious.
one difference is that in Water, EBuild does the entire build, including resolving inter-project dependencies etc… in VS, we rely on MSBuild for the core build of the solution (which might contain non-Elements projects), and it just shells out to EBuild for each individual project. As such, the project reference resolving is p to MSBuild and — suffice to say — EBuild is better at it, and many other things ;).
You will probably have to wade thru the MSBuild portions of a more verbose build log to see what fails extractly; my money would be on something not being 100% correct with the project reference — made the Guid doesnt match, or the project file path doesn’t:
<ProjectReference Include="TypeMismatchLibVB">
<Name>TypeMismatchLibVB</Name>
<Project>{d8290b36-f168-4518-8cde-d6c46abb5587}</Project>
<ProjectFile>..\TypeMismatchExample\TypeMismatchLibVB.vbproj</ProjectFile>
</ProjectReference>
shout;t this point to the .elements? (EBuild wot care, if the guid is correct, by MSBuild might).
the Guid looks correct; but it might also be that MSBuild doesnt like if they don’t match in case…
<ProjectGuid>{D8290B36-F168-4518-8CDE-D6C46ABB5587}</ProjectGuid>
(we auto-capitalize the one sin the project, coz VS sometimes freaks out when they aren’t; maybe I also ned to auto-capitalize the one in the project ref on Import.
How was this project & reference generated?
FWIW, the project compiles clean here for me too, in Fire, so I assume I’m not supposed to see the original bug in this one?
These projects were created in VS2019, and started out as VB (not Mercury) projects. My plan was to create simple VB projects that compiled successfully, then convert them to Mercury and show that it wasn’t working there with the error I was seeing, but I didn’t get that far because I started seeing this other issue.
Yeah, I actually hadn’t yet been able to recreate the issue I was seeing, and instead got distracted by the fact that this is behaving inconsistently between Water and VS2019.
If I get a chance I will dig into it some more and see if I can figure out why it is being cranky. Thanks for the pointers.
–Avonelle
Looks like converting the project in VS does not (yet) adjust the project oath in related project references, then (Fire/Water does this, but only if you convert them in the right order (ie, iff you convert a .vbptoj, any Elements projects that still reference that .vbproj get updated to reference the Elements. IOW, you need to update them from the referencer to the referencee). I’ll log.
Very interesting. I think I’ve been making these attempts in the reverse order, going from the referencee to the referencer. Good to know.
–Avonelle
At least for Fire/Water, the unconverted .vbproj is a “black box”; I don’t look inside it and we can’t* make changes to it. Only if the project that has the reference is already converted, do I see that reference in order to update it.
I haven an open issue to investigate to add an “convert all” option; in which case I could fix them all in one go.
*) for a certain definition of “can’t” :).
Makes sense. For me, I think I will end up staying in Visual Studio for most of my existing projects. While I haven’t done much in Water, my impression is that it doesn’t support some things my web development workflow would need, like SASS compilation and CSS minimization. (Let me know if I’m wrong about that.) I’m still on the fence regarding Visual Studio with Crossbox or Fire for the iOS development I’m hoping to get into.
–Avonelle
Correct. the Classic ASP.NET toolchain all requires MSBuild and VS. ASP.NET Core should work form EBuild/Water, but I dont believe there’s a step for CSS Minimization there at this stage (either in or chain or MS’s).
I’d definitely recommend Fire, there. going via CrossBox is, by very definition, an extra level of potential trouble (not to mention a speed factor in the build/deploy/test cycle, too)…
I’m not necessarily worried about this working during regular builds, but during the web development process I’m updating the CSS enough that I don’t think I’ll want to switch between Water and Visual Studio just to compile / minimize the CSS so I can test my web pages.
Yeah, that definitely has its appeal. Unfortunately my Mac Mini is in a different room, so I have to remote into it to use it, making Fire a little less attractive right now. Plus, I keep thinking that using Visual Studio means one less thing to learn, but that may not really be true in the end.
–Avonelle
Ah yeah. VS+CorssBox might be nicer to use than anything via VNC.
Yeah, I don’t think the learning curve will be that great. The main issue will be, once you used to Fire, you wont wanna go back to VS for anything. 