Reference to Oxygene 10 on build server can't resolve

visual-studio

(Mario Noack) #1

Hello Support,

Today we found a major problem for our build environment and we can reproduce it.

First, we create a VS C# project and an Oxygene project (attached, only for demonstration). C# use a class of the Oxygene project (VS2017, Net4.5.2), all works fine. We test it with RemObject 9.3.

Now we transfer this to our build server: Teamcity, latest release, RemObject, 9.3, latest VS2017 build tools. Again, all is fine (see detailed msbuild build server log RemObjTest_Build_RemObj9.3.Success in attached archive).

Now we update our local machine with RemObject 10 (stable and nightly), all works fine again like expected.

Now we update our build server to RemObject 10 (stable and nightly). Build server fails. Build task can compile the elements project without any problems. But C# build task forget the RemObject project to reference and we don’t know why. We attach also the detailed msbuild log from build server: RemObjTest_Build_RemObj10Fails.

We have no idea what’s wrong. We test this with a clean build server installation in a new virtual machine.

Mario

Test RemObject Compiler.zip (37,6 KB)


(marc hoffman) #2

Mario,

could I see a failed log with diagnostic output? (ie set <Debug>True</Debug> in your project).

What I find odd from the log is that — if I understand correctly — your VC# project depends on the Oxygene one, not vice versa, correct? but in the log file, the Oxygene project builds (successfully) last, after the VC# ones failed. It seems that the build on the build machine does not detect the proper dependency between the project, to order the accordingly.

I’ll ask my colleagues from the VS/MSBuild team side to look into that. In there mean timer, can you try if manually configuring the dependency inside the .sln file (via VS’s Project Dependencies dialog) works around the issue?

—marc


(Mario Noack) #3

Marc,

I attached the diag-Log for the msbuild failure.

Yes, VC# depends on the Oxygene one, not vice versa!

And yes, the Oxygene project is built successfully. It’s the second project in the solution, so it is compiled after the VC# project.

But: normally msbuild goes into VC# references and find all, VC# and Oxygene references. But with RemObj 10 msbuild find only VC# references. I don’t know why…

Mario

RemObjTest_Build_8.zip (17,9 KB)


(marc hoffman) #4

Does setting the dependency explicitly make it work? (I agree that should not be necessary, and its a bug still).


(Mario Noack) #5

Hello Marc,

I’m not sure if you mean following option:

This option is still selected by default.

Mario


(marc hoffman) #6

Hm, damn, I was hoping that VS would let you set an explicit reference even if it detects an implicit one :(.


(marc hoffman) #7

Vika tells me she reproduced the problem, but only with your solution, not a fresh one. We’re still investigating…


(RemObjects) #8

Thanks, logged as bugs://81590


(marc hoffman) #9

Mario,

I’ve uploaded a new build for you to Personal Downloads, .2352. Can you confirm whether that build solves there issue for you?

thanx,
marc


(Mario Noack) #10

Hello Marc,

I test it without success: RemObjTest_Build_8.zip (10,6 KB)

I see, your build 2352 is applied, but there is no change.

Mario


(marc hoffman) #11

:frowning:


(viktoriad) #12

Hello Mario,

Could you please open the “C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\RemObjects Software\Elements\RemObjects.Elements.Echoes.targets” file with any texteditor and check if Build and Rebuild targets have got next lines:

<Target Name="Build" Returns="$(FullOutputPath)">
...
<Target Name="Rebuild" Returns="$(FullOutputPath)">

It is important that Build and Rebuild targets have got the Returns part. If it is not there, could you please add it and see if you still can reproduce the issue?
Thanks in advance.


(Mario Noack) #13

I see only … so I don’t understand the task…
Here is my file (unchanged): RemObjects.Elements.Echoes.zip (3,2 KB)

Mario


(Carlo Kok) #14

hrmm this is tricky. We could (earlier) reproduce your issue but now are unable to, after the fixed target files. (The reason viktoria asked for the file was to make sure the setup really did update the installed file:

“C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\RemObjects Software\Elements” on the build server)

Neither of us can reproduce the error, I even just tried to to make this build in TeamCity where it also works.

Did you test it with the test project or with your real project?

If it’s the real one, does the test project still fail?


(Mario Noack) #15

Hello Carlo,

I get the problem first time on our build server. To reproduce it, I create a clean Win10 VM, install there only SVN, VS Buildtools, RemObject and Teamcity. For this issue, I use only my test-project (created with my external full VS2017 and uploaded to VM-SVN) and my test-buildserver.

So I can test “critical” software (UN) installation if necessary. But unfortunately I have no idea how I can fix it.

Mario


(marc hoffman) #16

Mario,

any chance one of my colleagues could connect directly to your test VM *(via Team Viewer) to debug this locally, sometime next week (or whenever it suits you, allowing for holidays; from our side, we should be around all week).

thanx!


(Mario Noack) #17

Hello Marc,

Can we postpone this to 7th or 9th january. You can connect into my VM, this is not a problem for me.

Thanks, Mario


(marc hoffman) #18

Sure, that’ll be fine. I have forgotten by then, so make sure you remind me ;).

Excellent; that should help us narrow this down…


(viktoriad) #20

Hello Mario,
I am writing to ask you if it is still possible to teamview the error on your machine? I will be able to do it today during the day or next week starting from Monday any day that is better for you. Please, let me know the login/password via private message and time when I can attach.
Thanks in advance.


(Mario Noack) #21

Hello,
I’ll send you connection data for a team viewer session via message. Today I can run this computer for 6 hours…
Thanks, Mario!