Recent Posts71
Darwinbots3 / Re: Trying to get darwinbots3 to build.
« Last post by Numsgil on December 30, 2019, 05:40:41 AM »Modules look for dependencies in Bin/Release/... You might double check that .dlls actually got put there after you ran build.py. Likewise in Visual Studio you might try expanding the "References" of a project and see if there's any broken links. DarwinbotsGUI has references to Azimuth there, for instance. I can tell you is I did a fresh checkout on my machine and it worked, but it's entirely possible there's some assumption I'm making about how stuff is setup that isn't true for everyone. I looked through the project files and didn't see any hard coded paths, for instance, but maybe there is one somewhere being sneaky.
Alternatively you might try looking at any local changes. It's possible that VS2017 tired to do an in-place upgrade that screwed some stuff up.
...
On purpose I didn't want to have one single solution. It may be overkill (arguably an enterprise solution) but it helps enforce separation of concerns and makes cloning one of the individual modules on another project easier (say, if I wanted to mess around in Unity with the Math library and not with the graphics library). I've also found that a single solution tends to dramatically inflate build times, even if it only contains projects that aren't changing, as Visual Studio has to scan for which projects have changes. I'm ideally aiming for build times of under 1 or 2 seconds to keep iteration time high. The downside is that it's harder to do a build of everything (though build.py is supposed to make that trivial) and I often need several visual studio instances open, one for each module.
Alternatively you might try looking at any local changes. It's possible that VS2017 tired to do an in-place upgrade that screwed some stuff up.
...
On purpose I didn't want to have one single solution. It may be overkill (arguably an enterprise solution) but it helps enforce separation of concerns and makes cloning one of the individual modules on another project easier (say, if I wanted to mess around in Unity with the Math library and not with the graphics library). I've also found that a single solution tends to dramatically inflate build times, even if it only contains projects that aren't changing, as Visual Studio has to scan for which projects have changes. I'm ideally aiming for build times of under 1 or 2 seconds to keep iteration time high. The downside is that it's harder to do a build of everything (though build.py is supposed to make that trivial) and I often need several visual studio instances open, one for each module.