Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

bazel run/bazel test only work in specific circumstances #9

Open
j3parker opened this issue Sep 6, 2019 · 1 comment
Open

bazel run/bazel test only work in specific circumstances #9

j3parker opened this issue Sep 6, 2019 · 1 comment
Assignees
@j3parker
Labels
bug Something isn't working
Milestone
Generally usable

Comments

@j3parker
Copy link
Member

j3parker commented Sep 6, 2019

Normally in C# you put all of your DLLs in one folder, and they are loaded based on filename (the full details are more complex).

In Bazel, when you have a target with dependencies in a different folder it will fail to run because the DLL can't be found.

Solutions that probably won't work:

  • Copying DLLs: in a large project like D2L this would become a performance/disk space issue.
  • app.config: you can use <probing> to add subdirectories for the loader to consider. The problem is you can't use .. so this won't handle all cases.

What I think will work:

Have an extra action that produces a shim exe, and also write the real exe path and the list of transitive dependencies to a txt file. The shim exe's Main function:

  1. Reads the txt file into a read only dictionary from Path.GetFilenameWithoutExtension to the path to the DLL
  2. hooks into the AssemblyLoad event and uses the list from (1) to resolve DLLs
  3. Loads the real exe assembly
  4. Calls the real Main( args ) (caution: Main() vs Main( string[] args ).. the runner would need to do the right thing).

In our DefaultInfo for executable rules we point at that shim, with the txt file as a runfile.

This probably makes sense to do after #8 because we should only need to make this exe once (probably for the latest .NET Core version?) but we could also do it for just .NET Framework first too.
@j3parker j3parker mentioned this issue Sep 8, 2019
Closed
@j3parker j3parker added this to the Generally usable milestone Sep 8, 2019
j3parker added a commit that referenced this issue Sep 11, 2019
@j3parker
Add runfiles to binary outputs
5942551 
This goes towards #9, but doesn't fix it. We still need to deal with how
these files aren't all collected into a single directory.
@j3parker j3parker mentioned this issue Sep 11, 2019
Merged
@j3parker j3parker self-assigned this Sep 11, 2019
j3parker added a commit that referenced this issue Sep 11, 2019
@j3parker
Add runfiles to binary outputs
27f7ec4 
This goes towards #9, but doesn't fix it. We still need to deal with how
these files aren't all collected into a single directory.
j3parker added a commit that referenced this issue Sep 11, 2019
@j3parker
Add runfiles to binary outputs (#35)
b00e2b6 
This goes towards #9, but doesn't fix it. We still need to deal with how
these files aren't all collected into a single directory.
@j3parker
Copy link
Member Author

I've got this broadly working but it doesn't make sense to check in until we support net48 + netcoreapp2.1 (the newest target frameworks that can produce exes).

I'm still investigating how runfiles work under the hood to see what stuff we have to DIY.

@j3parker j3parker added the bug Something isn't working label Sep 21, 2019
This was referenced Sep 23, 2019
Merged
Open
@j3parker j3parker mentioned this issue Oct 3, 2019
Closed
@j3parker j3parker mentioned this issue Dec 19, 2019
Merged
@j3parker j3parker mentioned this issue Jan 22, 2020
Open
4 tasks
j3parker added a commit to j3parker/rules_csharp that referenced this issue Mar 7, 2020
@j3parker
Generalize the dotnet wrapper a bit
5579d3f 
csharp_binary needs to become a rule which emits a cc_binary that
invokes "dotnet <foo>", where "<foo>" is the actual *.dll that we
compile, to solve Brightspace#71. Eventually <foo> will become a wrapper C# exe
that tweaks assembly loading to solve Brightspace#9. So all of this requires the
wrapper to provide a default argv[1].

For stuff like dotnet vstest (Brightspace#51) we will have argv[1] = vstest, so we
also need support for baking in argv[2].
@j3parker j3parker mentioned this issue Mar 7, 2020
Merged
j3parker added a commit to j3parker/rules_csharp that referenced this issue Mar 7, 2020
@j3parker
Generalize the dotnet wrapper a bit
3ad623a 
csharp_binary needs to become a rule which emits a cc_binary that
invokes "dotnet <foo>", where "<foo>" is the actual *.dll that we
compile, to solve Brightspace#71. Eventually <foo> will become a wrapper C# exe
that tweaks assembly loading to solve Brightspace#9. So all of this requires the
wrapper to provide a default argv[1].

For stuff like dotnet vstest (Brightspace#51) we will have argv[1] = vstest, so we
also need support for baking in argv[2].
j3parker added a commit to j3parker/rules_csharp that referenced this issue Mar 7, 2020
@j3parker
Generalize the dotnet wrapper a bit
ba5ba0b 
csharp_binary needs to become a rule which emits a cc_binary that
invokes "dotnet <foo>", where "<foo>" is the actual *.dll that we
compile, to solve Brightspace#71. Eventually <foo> will become a wrapper C# exe
that tweaks assembly loading to solve Brightspace#9. So all of this requires the
wrapper to provide a default argv[1].

For stuff like dotnet vstest (Brightspace#51) we will have argv[1] = vstest, so we
also need support for baking in argv[2].
j3parker added a commit to j3parker/rules_csharp that referenced this issue Mar 7, 2020
@j3parker
Generalize the dotnet wrapper a bit
3e7128c 
csharp_binary needs to become a rule which emits a cc_binary that
invokes "dotnet <foo>", where "<foo>" is the actual *.dll that we
compile, to solve Brightspace#71. Eventually <foo> will become a wrapper C# exe
that tweaks assembly loading to solve Brightspace#9. So all of this requires the
wrapper to provide a default argv[1].

For stuff like dotnet vstest (Brightspace#51) we will have argv[1] = vstest, so we
also need support for baking in argv[2].
j3parker added a commit to j3parker/rules_csharp that referenced this issue Mar 7, 2020
@j3parker
Generalize the dotnet wrapper a bit
1200f1c 
csharp_binary needs to become a rule which emits a cc_binary that
invokes "dotnet <foo>", where "<foo>" is the actual *.dll that we
compile, to solve Brightspace#71. Eventually <foo> will become a wrapper C# exe
that tweaks assembly loading to solve Brightspace#9. So all of this requires the
wrapper to provide a default argv[1].

For stuff like dotnet vstest (Brightspace#51) we will have argv[1] = vstest, so we
also need support for baking in argv[2].
j3parker added a commit to j3parker/rules_csharp that referenced this issue Mar 7, 2020
@j3parker
Generalize the dotnet wrapper a bit
8840f29 
csharp_binary needs to become a rule which emits a cc_binary that
invokes "dotnet <foo>", where "<foo>" is the actual *.dll that we
compile, to solve Brightspace#71. Eventually <foo> will become a wrapper C# exe
that tweaks assembly loading to solve Brightspace#9. So all of this requires the
wrapper to provide a default argv[1].

For stuff like dotnet vstest (Brightspace#51) we will have argv[1] = vstest, so we
also need support for baking in argv[2].
j3parker added a commit to j3parker/rules_csharp that referenced this issue Mar 7, 2020
@j3parker
Generalize the dotnet wrapper a bit
a3564d6 
csharp_binary needs to become a rule which emits a cc_binary that
invokes "dotnet <foo>", where "<foo>" is the actual *.dll that we
compile, to solve Brightspace#71. Eventually <foo> will become a wrapper C# exe
that tweaks assembly loading to solve Brightspace#9. So all of this requires the
wrapper to provide a default argv[1].

For stuff like dotnet vstest (Brightspace#51) we will have argv[1] = vstest, so we
also need support for baking in argv[2].
j3parker added a commit that referenced this issue Mar 7, 2020
@j3parker
Generalize the dotnet wrapper a bit (#131)
5531b47 
csharp_binary needs to become a rule which emits a cc_binary that
invokes "dotnet <foo>", where "<foo>" is the actual *.dll that we
compile, to solve #71. Eventually <foo> will become a wrapper C# exe
that tweaks assembly loading to solve #9. So all of this requires the
wrapper to provide a default argv[1].

For stuff like dotnet vstest (#51) we will have argv[1] = vstest, so we
also need support for baking in argv[2].
@j3parker j3parker mentioned this issue Nov 16, 2020
Open
@j3parker j3parker mentioned this issue Apr 13, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@j3parker j3parker

Labels
bug Something isn't working
Projects
None yet
Milestone
Generally usable
Development

No branches or pull requests
1 participant
@j3parker