[Storage] Added DataLake projects to Storage #7772
Conversation
seanmcc-msft
added
Storage
seanmcc-msft
changed the title
sdk/storage/Azure.Storage.Files.DataLake/src/Azure.Storage.Files.DataLake.csproj
Outdated
Show resolved
Hide resolved
sdk/storage/Azure.Storage.Files.DataLake/samples/Azure.Storage.Files.DataLake.Samples.csproj
Outdated
Show resolved
Hide resolved
seanmcc-msft
force-pushed
the
storage/features/DataLake
branch
from
32474a5 to
e794583
Compare
|
/azp run net - storage - ci |
|
Azure Pipelines successfully started running 1 pipeline(s). |
seanmcc-msft
requested review from
chidozieononiwu,
danieljurek,
mitchdenny and
weshaggard
as code owners
|
So it looks like Azure.Storage.DataLake.Tests and Azure.Sotrage.DataLake.Samples can't access the Azure Core testing stuff. I'm using #7598 as a reference, but I'm not sure what I'm missing. |
seanmcc-msft
force-pushed
the
storage/features/DataLake
branch
from
51dee60 to
992bd84
Compare
| "960D89BA2E25561F70B0E2DBC93319E0AF1961A719CCF5A4D28709B2B57A5D29B7C09DC8D269A4" + | ||
| "90EBE2651C4B6E6738C27C5FB2C02469FE9757F0A3479AC310D6588A50A28D7DD431B907FD325E" + | ||
| "18B9E8ED")] | ||
| [assembly: InternalsVisibleTo("Azure.Storage.Files.DateLake.Tests, PublicKey=" + |
There was a problem hiding this comment.
Typo: DateLake. Here is problem number 1.
|
The other problem was the Azure.Storage.Files.DataLake.Samples.Tests project was named Azure.Storage.Files.DataLake.Samples. |
seanmcc-msft
force-pushed
the
storage/features/DataLake
branch
from
992bd84 to
8eed935
Compare
| @@ -15,3 +15,15 @@ | |||
| "012ea67d2479751a0b8c087a4185541b851bd8b16f8d91b840e51b1cb0ba6fe647997e57429265" + | |||
| "e85ef62d565db50a69ae1647d54d7bd855e4db3d8a91510e5bcbd0edfbbecaa20a7bd9ae74593d" + | |||
| "aa7b11b4")] | |||
| [assembly: InternalsVisibleTo("Azure.Storage.Files.DataLake, PublicKey=" + | |||
There was a problem hiding this comment.
Can I ask why we need internal access? It is generally a bad idea to couple these libraries like this. It will force use to always ship them together to ensure we don't break the internal api usage as well as means customers will always have to use the matching versions of these libraries as well to avoid breaking.
There was a problem hiding this comment.
We might not, we'll see later during the implementation. The intention is to only be dependent on the public blob interfaces.
There was a problem hiding this comment.
Yes it would be best if we can depend only on the public apis.
No description provided.