Can't build from editor but build works from visual studio about stride HOT 22 CLOSED

We can't really control the SDK path as we simply defer most of the job to MSbuild, like Visual Studio does. The fact it is on D shouldn't bother.

So we'll have to investigate what is wrong, could be the tip of a bigger iceberg (maybe something that should be an absolute path but is a relative path, resulting in losing the HDD part of the path, etc...).

from stride.

Install the .NET Core build tools from the Visual Studio 2017 installer.

from stride.

I already did it, i can build the xenko project from visual studio, but xenko gamestudio doesn't find it

from stride.

That toolset is for Visual Studio, you need the .Net Core for Visual Studio Build Tools.

from stride.

i tried, didn't work either, but as i said it's probably because i use the D drive, you're using the C drive in your case so there's no problem for you

from stride.

So at the moment i'll start prototyping my game using unity since xenko doesn't want to work, but once there will be a fix, i would gladly switch back to xenko since i love the xenko api and interface, i just need it to work

from stride.

Hm, that could be the case. Though just as a last check/thing to try do you have
.NET Framework 4.6 targeting pack
.NET Framework 4.6.1 SDK
.NET Framework 4.6.1 targeting pack

Installed for Build Tools (and Visual Studio)?

I had the same problem as you but managed to fix it with some tinkering.

from stride.

yes, and for both

from stride.

Sorry, I'm not sure what I'm missing here. When I had this problem myself I was able to fix it by following some of the suggestions in dotnet/msbuild#2532

It could've been adding "C:\Program Files\dotnet" to my Path environment variable and rebooting... Can't say for certain that will work but give it a shot if you're still up for trying.

from stride.

i tried it, didn't work either
well, it changed the problem but i still get errors caused by the fact that it doesn't find a kind of "telemetry" task in the dotnet core sdk

from stride.

That's too bad. Could be a Windows 10 only thing as I never had that issue come up. Regardless, new users shouldn't have to go through all this just to try Xenko, its not a good first look.

If you don't manage to fix it yourself, check back in a couple weeks/whenever the next version releases, hopefully the set-up process should be much more straightforward by then.

from stride.

Regardless, new users shouldn't have to go through all this just to try Xenko, its not a good first look.

That's only because @pikachuk setup is not standard. If you want to be a super user and change default behaviours/expected paths of software and tools, don't expect any software vendor to support any and all exotic configurations that people can come up with.

I'm pretty sure mixing C: drive and D: drive for .Net Dev/SDK tools is not properly supported by itself.

@pikachuk Any compelling reason why you don't install them in your C: drive? When I have a setup with multiple drives and/or partitions, I usually keep everything system-related (that includes SDKs) on the main drive and only move data/projects on the secondary drive. The reason is that most tools also rely on system processes/files that live in the Windows, Program Data or default Program Files folders (for example the GAC). But having such tools split into several drives only make it slower/unreliable (incorrect PATH, duplicates in both drive/partition, disk seeks, etc.).

from stride.

I wasn't able to install them on the C drive because of limited space (i've a 80gb hdd for the boot drive, windows already fills a good part, i can't put the sdks on it, everything is on my 1tb D drive)

i feel like a good fix would be to be able to manually set the sdks path in xenko settings when it doesn't detect them automatically

from stride.

@pikachuk You are right. We can explore a way to have some parts of the PATH overridden in the settings. I I don't believe that it will fix all possible issues, but if it can at least fix yours that's already a win.

I wonder if that should be global or on a per-project basis.

from stride.

maybe both, a section for project specific settings and a section for default settings

from stride.

if it does the same as visual studio it's weird that the build works on visual studio but not on the xenko gamestudio...
is there something i could do to help you to identify the problem ? like a kind of debug mode that displays every single search path etc in the xenko console ?

from stride.

@xen2 I found a webpage that might explain the problem and it seems it can be fixed by using FrameworkPathOverride in the msbuild command https://dzone.com/articles/how-i-resolved-the-error-the-reference-assemblies since xenko calls msbuild, using the frameworkpathoverride in the msbuild command might help to avoid issues

from stride.

so a fix would be to be able to set manually the framework path and it would be added to the msbuild command for the build

from stride.

Just checking, is it still an issue? Does everything work better with latest 3.0 or 3.1?

from stride.

well I changed of pc since then and I didn't get any issues on my new pc

from stride.

I downloaded the engine to test and tried running First Person Shooter example, it gave this output: [D:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1175,5)]: Error:The reference assemblies for framework ".NETFramework,Version=v4.6.1" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

from stride.

I was able to resolve this on my computer, after experiencing a similar issue again with a different .NET project (OmniSharp).

Issue

I discovered that my system contained both a C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework and a D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework directory. The C: directory contained many versions within .NETCore, .NETFramework, and .NETPortable subfolders, but the D: directory only had subfolders for v3.0 and v3.5. I presume that Visual Studio Installer was placing these in the C: folder, but they were being looked for in the corresponding D: folder.

Solution

To resolve this, I first removed the version of the Frameworks folder in the D: filesystem, leaving D:\Program Files (x86)\Reference Assemblies\Microsoft as an empty directory. Then, I ran the following in Command Prompt as Administrator:

mklink /J "D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework" "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework"

After this created a symlink directory junction, the issue disappeared and I am now able to build from the editor.

from stride.