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.

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

Feature : Allow project reference DLLs to be added to the parent nupkg for pack target like IncludeReferencedProjects in nuget.exe #3891

Open
joelverhagen opened this Issue Nov 8, 2016 · 78 comments

Comments

@joelverhagen
Member

joelverhagen commented Nov 8, 2016

Steps

  1. dotnet new --type lib two .csproj class libraries: projectA and projectB.
  2. Change <TargetFramework> to <TargetFrameworks> if you don't have #3865.
  3. Make projectA have a ProjectReference to projectB.
  4. Add <Type>project</Type> to the <ProjectReference>.
  5. dotnet pack projectA
  6. Open the resulting .nupkg's lib folder

Expected

projectB.dll should be in the .nupkg along with projectA.dll

Actual

projectB is still a package reference, not a DLL included in the package.

Environment

Tried latest dev's pack target.

dotnet --info

.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
 Version:            1.0.0-preview3-004056
 Commit SHA-1 hash:  ccc4968bc3

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

UPDATE: Please see workaround posted as comment to see how to add ProjectReferences as DLLs in the package dynamically.

@joelverhagen joelverhagen added this to the 4.0 RC2 milestone Nov 8, 2016

@rrelyea

This comment has been minimized.

Contributor

rrelyea commented Nov 8, 2016

Please check spec on wiki for planned behavior

@joelverhagen

This comment has been minimized.

Member

joelverhagen commented Nov 8, 2016

Spec: https://github.com/NuGet/Home/wiki/Adding-nuget-pack-as-a-msbuild-target

This doesn't work:

<TreatAsPackageReference>false</TreatAsPackageReference>

The output .nuspec still has projectB as a package reference and only one file: projectA.dll under lib.

@emgarten

This comment has been minimized.

Collaborator

emgarten commented Nov 8, 2016

This is a non-trivial feature that hasn't been implemented for RC yet.

Supporting this will require potentially walking the entire project closure to determine all projects that need to be merged into the package, or reading the assets file and matching the project closure with both the project reference flags and the pack flags found in the project (since it can be set either way).

This is also impacted by build outputs not flowing transitively to parent projects yet.

@joelverhagen

This comment has been minimized.

Member

joelverhagen commented Nov 10, 2016

Plan of action:

  1. Build out some automated tests for pack task to cover basic scenarios and detect regression.
  2. Add the original PackageSpec to the lock/assets file.
  3. Add any missing properties to the assets file pack needs (e.g. path to child project output assemblies).
  4. Update restore (no, not pack) to collapse project references when <TreatAsPackageReference> is true.
  5. Move the PackTask away from looking at child projects. Look at restore's assets file instead.

This has repercussions on:

  • Restore: basically all of the data pack needs should be collected by restore an put in the assets file. Restore should be the only guy doing a walk.
  • Project/Package duality: what if a child project .csproj has a <Reference>. How is this collapsed?
  • What collapsing occurs? Certainly build artifacts and <PackageReference>... what about <Reference>?

@joelverhagen joelverhagen self-assigned this Nov 14, 2016

@rrelyea rrelyea modified the milestones: 4.0 RC2, 4.0 RC3 Nov 29, 2016

@joelverhagen joelverhagen removed their assignment Dec 7, 2016

@joelverhagen

This comment has been minimized.

Member

joelverhagen commented Dec 7, 2016

@rohit21agrawal, I partially got through consuming the assets file from in the pack task:
https://github.com/joelverhagen/NuGet.Client/tree/jver/3891

This also has some progress on getting the output DLLs of child projects (using @(ReferenceCopyLocalPaths) MSBuild items).

This branch is pretty rough so let me know if I can clarify.

@rohit21agrawal

This comment has been minimized.

Contributor

rohit21agrawal commented Dec 9, 2016

As per @rrelyea : #3893 (comment)

"We don't plan to enable this in dotnet pack / msbuild /t:pack in 4.0 timeframe.
We'll listen to customer feedback and consider in the future."

@rohit21agrawal

This comment has been minimized.

Contributor

rohit21agrawal commented Dec 15, 2016

moving to future as this is post-rtm work.

@rohit21agrawal rohit21agrawal modified the milestones: 4.0 RTM, 4.0 RC3 Dec 15, 2016

@gulbanana

This comment has been minimized.

gulbanana commented Dec 15, 2016

building a nupkg from multiple projects seems like a major feature to be missing :/

@rohit21agrawal

This comment has been minimized.

Contributor

rohit21agrawal commented Dec 15, 2016

@gulbanana thanks for the feedback. this is something that is not planned for the 4.0 RTM release, but this is something we will definitely address in a future release.

@bbowman

This comment has been minimized.

bbowman commented Dec 15, 2016

@kzu 's nugetizer 3000 does this?

@Cloudmersive

This comment has been minimized.

Cloudmersive commented Aug 4, 2018

When is this going to get fixed?? This is such a mess

vicancy added a commit to Azure/azure-signalr that referenced this issue Sep 10, 2018

Add dependencies from Common project to here
Although `PrivateAssets` and set workarounds as NuGet/Home#3891 (comment) shows, it is unable to detect what Common project references and add it to the references of current project.
So for now, we still need to make sure the references of Common project is added to this project's references, until NuGet/Home#3891 is resolved.

vicancy added a commit to Azure/azure-signalr that referenced this issue Sep 10, 2018

Add dependencies from Common project to here (#193)
Although `PrivateAssets` and set workarounds as NuGet/Home#3891 (comment) shows, it is unable to detect what Common project references and add it to the references of current project.
So for now, we still need to make sure the references of Common project is added to this project's references, until NuGet/Home#3891 is resolved.

vicancy added a commit to Azure/azure-signalr that referenced this issue Sep 20, 2018

Add dependencies from Common project to here (#193)
Although `PrivateAssets` and set workarounds as NuGet/Home#3891 (comment) shows, it is unable to detect what Common project references and add it to the references of current project.
So for now, we still need to make sure the references of Common project is added to this project's references, until NuGet/Home#3891 is resolved.

vicancy added a commit to Azure/azure-signalr that referenced this issue Sep 20, 2018

Add dependencies from Common project to here (#193)
Although `PrivateAssets` and set workarounds as NuGet/Home#3891 (comment) shows, it is unable to detect what Common project references and add it to the references of current project.
So for now, we still need to make sure the references of Common project is added to this project's references, until NuGet/Home#3891 is resolved.

vicancy added a commit to Azure/azure-signalr that referenced this issue Sep 20, 2018

Add Microsoft.Azure.SignalR.AspNet.csproj and SDK skeleton (#144)
* Add Microsoft.Azure.AspNet.SignalR.csproj and SDK skeleton

* Remove unneccessory package reference

* Rename to Microsoft.Azure.AspNet.SignalR

Implement RunAzureSignalR in the API, add necessory class skeleton

Resolve comments, and make ServiceOptions configurable

Add test project and RunAzureSignalR test

fix format: using System directives should be first

Add 2 to-dos

Reference Common project

update interface (#158)

Implement ServiceConnection for Azure AspNet Service (#159)

* Implement ServiceConnection for Azure AspNet Service, dispatcher should be per connection per instance, and add a TCS when service connection starts

Implement ConnectionFactory, and add a container for partitional writ… (#175)

* Implement ConnectionFactory, and add a container for partitional write message

* Use a more effective way to json serialize, and remove AddConnection from manager

* return 400 for JSONP

[ASP.NET SignalR]Implement ServiceEndpointPrvoider for ASP.NET SignalR SDK (#182)

* Implement ServiceEndpointPrvoider for ASP.NET SignalR SDK

Update the negotiate response (#186)

1. `ProtocolVersion` up to 2.0
2. Use `RedirectUrl` instead of already in-use `Url`

try to support /reconnect (#187)

* try to support /reconnect

Add dependencies from Common project to here (#193)

Although `PrivateAssets` and set workarounds as NuGet/Home#3891 (comment) shows, it is unable to detect what Common project references and add it to the references of current project.
So for now, we still need to make sure the references of Common project is added to this project's references, until NuGet/Home#3891 is resolved.

Add application name to the public API (#190)

* Add application name to the public API, and add comments, add an app connection to the service connection

Fix userid can be null (#204)

Make the one from web.config as the default connection string and fix build failure (#206)

* Fix build failure

* Make the one from web.config as the default connection string

* Add appsettings support

[ASP.NET SignalR]Implement ServiceMessageBus and ServiceConnectionManager (#152)

* Implement ServiceMessageBus and ConnectionManager

vicancy added a commit to Azure/azure-signalr that referenced this issue Sep 20, 2018

Merge AspNet related changes to dev branch (#209)
* Add Microsoft.Azure.SignalR.AspNet.csproj and SDK skeleton (#144)

* Add Microsoft.Azure.AspNet.SignalR.csproj and SDK skeleton

* Remove unneccessory package reference

* Rename to Microsoft.Azure.AspNet.SignalR

Implement RunAzureSignalR in the API, add necessory class skeleton

Resolve comments, and make ServiceOptions configurable

Add test project and RunAzureSignalR test

fix format: using System directives should be first

Add 2 to-dos

Reference Common project

update interface (#158)

Implement ServiceConnection for Azure AspNet Service (#159)

* Implement ServiceConnection for Azure AspNet Service, dispatcher should be per connection per instance, and add a TCS when service connection starts

Implement ConnectionFactory, and add a container for partitional writ… (#175)

* Implement ConnectionFactory, and add a container for partitional write message

* Use a more effective way to json serialize, and remove AddConnection from manager

* return 400 for JSONP

[ASP.NET SignalR]Implement ServiceEndpointPrvoider for ASP.NET SignalR SDK (#182)

* Implement ServiceEndpointPrvoider for ASP.NET SignalR SDK

Update the negotiate response (#186)

1. `ProtocolVersion` up to 2.0
2. Use `RedirectUrl` instead of already in-use `Url`

try to support /reconnect (#187)

* try to support /reconnect

Add dependencies from Common project to here (#193)

Although `PrivateAssets` and set workarounds as NuGet/Home#3891 (comment) shows, it is unable to detect what Common project references and add it to the references of current project.
So for now, we still need to make sure the references of Common project is added to this project's references, until NuGet/Home#3891 is resolved.

Add application name to the public API (#190)

* Add application name to the public API, and add comments, add an app connection to the service connection

Fix userid can be null (#204)

Make the one from web.config as the default connection string and fix build failure (#206)

* Fix build failure

* Make the one from web.config as the default connection string

* Add appsettings support

[ASP.NET SignalR]Implement ServiceMessageBus and ServiceConnectionManager (#152)

* Implement ServiceMessageBus and ConnectionManager

* disable net461 tests and samples in travis and add appveyor

Skip test related reference

* Add appveyor build status

* Update SignalR SDK version

* Update sources.props

vicancy added a commit to Azure/azure-signalr that referenced this issue Sep 20, 2018

Merge dev to master for releasing 1.0.0 (#211)
* New protocol used for SDK and Service (#11)

* New protocol used for SDK and Service

This PR is a subset of PR
#10. It is just for code
review purpose.

* update the dictionary if the same key existed

Add timestamp for metric requirement

* refactor code according to review comments

* refactor the protocol per review comments

* Service protocol for making refactoring version work (#16)

The service protocol still needs to be refactoring in next step.

* New SDK API and architecture refactor (#17)

* SDK new API and architecture refactoring

This commit includes:
1. architecture refactoring (all in HubHost folder, and has been reviewed)
2. API refactor: HubProxy and ServiceProvider folders
3. negotiation response implementation: HubHostBuilder.cs
4. ChatSample refactor: refers to relative new signalr.js, using new API

* rollback the change of VS version

* Fix most issues accroding to review comments

* remove unnecessary Task returun

* handle the connection completion

* gracefully complete the connection pipes when client drops

* Use the SignalR of Apr 18 to make client negotiate work

The client javascripts are copied from SignalR with CI:

commit f36313e58519dec240b3f327489995ffcdcb4056
Merge: 9a0c190f e9937ffb
Author: BrennanConroy <brecon@microsoft.com>
Date:   Wed Apr 18 17:45:08 2018 -0700

* simplify the logic to start HubConnection

* Try to gracefully close of client connection

* gracefully close pipe

* correct the logic of WaitOnTask

* Update the REST API

1. SignalRServiceContext is the interface to use.
2. Hub does not make sense in REST API under severless mode.
3. In order to communicate with SignalR service, I need to create my own
service provider to access SignalR protocol.

* Remove 'SignalR' prefix

* explain why we need all protocols

* fix a compilation issue

* New service protocol(#21)

* Refine REST API and ServiceOptions (#22)

* Refine REST API and ServiceOptions

1. AddAzureSignalR will register a default ServiceOptions
2. Fix an issue of CreateServiceContext
3. Rename the classes
4. Using option to get connection string in ChatSample

* refine the error message

* API refactor

1. For AddAzureSignalR(), we read connection string by
ServiceOptionSetup which looks up connection string from Configuration.
2. Add a standalone console application to demonstrate Rest API usage.

* Using AddAzureSignalR(connectionString) in CloudSignalR

* remove unnecessary dependency on MessagePack

* refine according to review comments

* use SendAsync overload directly

* Use new service protocol (#24)

* Make the OWIN project compile (#30)

* Made some perf changes and sample changes (#31)

- Use ReadOnlyMemory in ConnectionDataMessage
- Use IReadOnlyList<string> instead of string[] in protocol messages. This lets us remove ToArray() everywhere.
- Don't copy the buffer twice when writing it from the application pipe to the service connection. Just write the memory as is.
- Updated the sample to use the default connection string config key.

* Use all claims by default (#32)

- If no delegate was specfied then use all of the current user's claims.
- Renamed Claims to ClaimsProvider

* Fixed sample from merge

* Use the default WebHostBuilder (#33)

* Upgrade to the latest SignalR rc1 build (#34)

- Some things were made internal
- Added a test project and a fake test to make sure we can run more.

* Slight refactoring and renaming (#35)

- Remove ConnectionProtocol and ServiceResponse
- Change protocol to types to use ReadOnlyMemory<byte> instead of byte[]
- Rename methods (WriteAsync and StartAsync)

* Fixed null ref

* Send directly to the connection if we have a mapping (#36)

- Sending directly to a connection shorts writes to the hub connection context if it can.

* Improve error message and delete connection string from config. (#38)

* Improve error message and delete connection string from config.

* initial clean up of Rest API code (#39)

* Update to the latest SignalR and ASP.NET Core dependencies (#41)

* Dispose the HttpConnection if StartAsync fails (#40)

- This shouldn't matter as much but it's more correct to dispose the httpConnection if StartAsync fails. See aspnet/SignalR#2134.
- The reason it shouldn't matter is because we both skip negotiation and are using websockets which means we shouldn't ever allocate an HttpClient.

* Send server Id to service (#42)

* Send server's user Id to Service when connecion

* make sure we only generate single userId for all connections

* use machine name + GUID as server Id

It is friendly for diagnostic.

* reconnection implementation (#26)

* implement reconnection

implement reconnection

refactor the loop

refine per review comments

* Do not clean client connection contexts unless service asks to

Some cleaning up to align with async/await single loop pattern

* add "CleanupConnections" back

* rename

* remove _connected and refactor AbortOnClose

* add the missing lock check

* safely stop the connection in timer's callback

* remove unnecessary null check

* remove the locker helper

* Fix issue and polish code

* small fixes

* Renames and cleanup (#43)

- Moved public APIs to the root
- Renamed classes to add the Service* prefix

* provide default value for connection count (#44)

* Remove CloseTimeout (#45)

- We don't want to wait 300 seconds for the other side to close the websocket.

* Use the latest javascript client (#47)

* Don't pass the ConnectionDelegate in StartAsync (#46)

- Make it part of the ServiceConnection construction

* Add a heartbeat (#49)

* Add a heartbeat
- Implement the required features to support sending keep alives

* Handle shutdown properly (#51)

- Don't close the application input, we already complete it when the transport stops writing
- Handled exceptions leaking from the application task
- Added comments and fixed method names

* Make AccessTokenLifetime configurable (#52)

- Default to 1 hour instead of 30 seconds
- Added error message when connection string fails to parse

* refine log (#53)

* refine logs
close the issue #27

* Enable user secrets (#58)

* set connectionID for HttpConnection (#59)

generate connection ID for each service connection, and pass "cid=connectionId" through query string to service.

* build scripts (#61)

add scripts for build

BuildTools is applied for our build. The same as SignalR used for build.
Give the developers consistent building experience.

All scripts come from:
https://github.com/aspnet/BuildTools/tree/dev/scripts/bootstrapper
It is very easy to build on both Windows and Linux:

build.cmd or build.sh

They will install the required dotnet in your system. It will try to
find the *.sln to build and run test defaultly.

* Quit the loop if the connection closed (#63)

* Some updates to korebuild usage (#64)

- Pin korebuild to the release 2.1 branch
- Check in a korebuild-lock.txt which will pin the resolved version
- Make the .sh files executable with chmod

* Delete OWIN project (#65)

* Remove OWIN project from solution

* Add handshake with service (#67)

* Always read connection string defaults from config (#70)

* Always read connection string defaults from config
- Added tests

* Remove REST Api support in SDK (#71)

* Remove dependencies and delete the REST sample (#72)

* Code clean up (#73)

- Remove small async methods that are called once
- Remove extra async state machines

* upgrade to 1.0.0-rc1-30677 (#74)

* Add service protocol test case & add doc comments (#75)

* add service protocol test case
* add doc comments

* Refine connection string parsing (#78)

* update package name to 1.0.0-preview1-* (#80)

* Add swagger file and update README (#81)

* Update dependencies to rc1-final (#82)

* Enable travis ci build

* Add build status to README.md

* Point package links to Nuget (#86)

* Fix format in README (#88)

* Add missing XML doc (#92)

* Fixed auth and tests (#90)

- Made it so tests don't depend on timeouts
- Fixed the auth bug and added unit tests

* Update external files and remove unused (#93)

* Make AuthenticationHelper internal (#94)

* Make AuthenticationHelper internal

* Added timeout to tests to make sure things don't hang if there's a bug (#95)

* Added timeout to tests to make sure things don't hang if there's a bug
* Fix races in test

* Added more ServiceConnection tests (#96)

* Support multiple hubs (#98)

* WIP

* Removed Hub

* Updated to netcoreapp2.1 added another hub to sample

* fix issue #99 (#100)

Korebuild's config for dotnet SDK needs to be updated. Otherwise, it reports exception:
"Could not load file or assembly 'System.Memory, Version=4.1.0.0, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51'"

dotnet 2.1.300-rc1-008673 works fine. But lower version has this issue.

* Add signing project (#103)

* Add signing proj

* Add Microbuild Reference

* Add parameters into dependencies

* Fix MultiUserDataMessage type (#105)

* Use condition PackageReference in MicroBuild (#106)

* send PingMessage to service to keep alive (#102)

* Add package restore tests (#111)

* Add restore test

* More parameterize

* Update version

* filter claims in OpenConnectionMessage for unauthenticated user (#107)

* update SignalR dependencies to 1.0.0 (#114)

* Change Microbuild PackageReference to a separate proj (#116)

* change sign dependency

* Update

* add required metadata for nuget package (#117)

* add API descriptions in swagger (#128)

* Write the ReadOnlySequence as a single ConnectionDataMessage (#130)

- Manually write the message pack header and ReadOnlySequence to the Stream directly.
- Added IClientConnectionFactory to make it possible to override creation of client connections.
- Added test for writing multi segment message through the ServiceConnection.

* load connection string from ConnectionStrings section if default key not exist (#129)

* Add headers and query string in OpenConnectionMessage (#131)

* Throw more friendly exception when calling AddAzureSignalR without UseAzureSignalR (#136)

* Show friendly message if not call UseAzureSignalR

* Add blank line

* Change parameter name and add more check so that exception message can be more friendly.

* Add test case

* Push private package to myget (#137)

* Update travis to push package

* update travis

* update travis

* Fix dotnet not found (#138)

* update travis

* Fix wrong options in dotnet nuget push (#139)

* Add Test cases for EndpointUtilty, LifetimeManager and ServiceConnection (#133)

* Add EndpointUtilty Test

* Add tests for lifetimeManager

* Add LifetimeManager IT

* Format the codes

* Format codes

* Remove mock and use TestClass instead.

* Add a few reconnection test

* Add message fieds verification

* Add reconnect test

* Update reconnection test

* Update reconnection when connection throws exception

* Update reconnection logic

* Format codes

* Add keepalive reconnect

* Fix typo

* fix merge conflict

* clean up test infrastructure

* PR comments

* fix typo

* Add Endpoint validation (#142)

* Add endpoint validation

* Fix typo

* Update error message and add tests

* Avoid connection timeout when debugger is attached (#143)

For ServiceConnection Handshake, for better debugging experience

* Update xunit related test package version (#146)

to latest

* Add custom UserAgent for general telemetry tracking (#148)

Add custom UserAgent for general telemetry tracking

* send group message from a fixed service message (#147)

* Extract a base connection class to for service connection and utiliti… (#155)

* Extract a base connection class to for service connection and utilities (#153)

* Extract a base connection class to for basic service connection actions, such as keepalive, handshake, and process incoming messages to a Common csproj
* Change all class to internal as it is a SDK project

* support version in connection string. (#154)

* rename IServiceEndpointUtility to IServiceEndpointProvider. (#157)

* Add Constants to Common project (#164)

* Shorten AzureSignalRPrefix in claimType, as longer one will be result… (#165)

* Shorten AzureSignalRPrefix in claimType, as longer one will be resulted in longer url

* Loop over the dictionary itself rather than keys (#168)

> Performance tip: It's more efficient to loop over the ConcurrentDictionary itself rather than keys or values. Each of those collections takes a lock on all of the buckets.

* Send UpdateConnectionMessage when there is custom IUserIdProvider (#163)

* Revert "Send UpdateConnectionMessage when there is custom IUserIdProvider (#163)" (#171)

This reverts commit 52cfc85.

* Use IUserIdProvider to generate user id and include it in access token (#170)

* Change partitioning hashset algorithm (#177)

* Refactor ServiceEndpointProvider (#176)

* Include CustomUserId claim as internal claims (#178)

* Check system claims in a case-sensitive way (#180)

* Move ConnectionStringParser and IServiceEndpointGenerator to Common p… (#181)

* Move ConnectionStringParser and IServiceEndpointGenerator to Common project

* Move tests too

* Preserve original request path of client connection (#179)

* Include original query string in negotiate response (#184)

* Add missing copyright (#185)

* Minor refine of README (#188)

* Fix a VSTS restore test bug (#201)

* change suffix to rtm

* fix restore bugs

* change back to preview1

* Add swagger and documentation for V1 REST API (#195)

* rename custom header name to avoid header restriction in asp.net framework (#200)

* rename custom header name to avoid header restriction in asp.net

* add comments for the fix.

* header name convention

* Add client IP address in Context.HttpContext (#207)

* Merge AspNet related changes to dev branch (#209)

* Add Microsoft.Azure.SignalR.AspNet.csproj and SDK skeleton (#144)

* Add Microsoft.Azure.AspNet.SignalR.csproj and SDK skeleton

* Remove unneccessory package reference

* Rename to Microsoft.Azure.AspNet.SignalR

Implement RunAzureSignalR in the API, add necessory class skeleton

Resolve comments, and make ServiceOptions configurable

Add test project and RunAzureSignalR test

fix format: using System directives should be first

Add 2 to-dos

Reference Common project

update interface (#158)

Implement ServiceConnection for Azure AspNet Service (#159)

* Implement ServiceConnection for Azure AspNet Service, dispatcher should be per connection per instance, and add a TCS when service connection starts

Implement ConnectionFactory, and add a container for partitional writ… (#175)

* Implement ConnectionFactory, and add a container for partitional write message

* Use a more effective way to json serialize, and remove AddConnection from manager

* return 400 for JSONP

[ASP.NET SignalR]Implement ServiceEndpointPrvoider for ASP.NET SignalR SDK (#182)

* Implement ServiceEndpointPrvoider for ASP.NET SignalR SDK

Update the negotiate response (#186)

1. `ProtocolVersion` up to 2.0
2. Use `RedirectUrl` instead of already in-use `Url`

try to support /reconnect (#187)

* try to support /reconnect

Add dependencies from Common project to here (#193)

Although `PrivateAssets` and set workarounds as NuGet/Home#3891 (comment) shows, it is unable to detect what Common project references and add it to the references of current project.
So for now, we still need to make sure the references of Common project is added to this project's references, until NuGet/Home#3891 is resolved.

Add application name to the public API (#190)

* Add application name to the public API, and add comments, add an app connection to the service connection

Fix userid can be null (#204)

Make the one from web.config as the default connection string and fix build failure (#206)

* Fix build failure

* Make the one from web.config as the default connection string

* Add appsettings support

[ASP.NET SignalR]Implement ServiceMessageBus and ServiceConnectionManager (#152)

* Implement ServiceMessageBus and ConnectionManager

* disable net461 tests and samples in travis and add appveyor

Skip test related reference

* Add appveyor build status

* Update SignalR SDK version

* Update sources.props

* fix claim in negotiate handler. (#205)
@houseofcat

This comment has been minimized.

houseofcat commented Sep 29, 2018

I would love to have been in the room where they decided to make this a much more streamlined process. It is so much easier than old Framework package maintenance.... but then right at the end, the design topic of including other project references into dotnet pack comes up... and it looks like they figuratively drove the whole god damn bus off a cliff.

@josh-endries

This comment has been minimized.

josh-endries commented Oct 5, 2018

Two years, multiple issues, over a hundred comments, still not prioritized. Wow guys. Impressive.

This also doesn't work with dotnet build and <GeneratePackageOnBuild>true</GeneratePackageOnBuild>, by the way.

@ChristianSauer

This comment has been minimized.

ChristianSauer commented Oct 8, 2018

Honestly, we are considering ditchting .Net Core and nuget over this.
We are building microservices which share some commen infrastructure and deploying them using nuget is difficult due to this issue.
Even python packages work better than this.
Hell, I would be satisfied if I could write this by hand, but the whole mess (including sourcelink now) is so complicated that the amount of time needed is prohibitive.

@HristoHentov

This comment has been minimized.

HristoHentov commented Oct 15, 2018

Just spent half a day thinking I was doing something wrong with my project setup, only to find out this behavior is by design. Really disappointed

joelmartinez added a commit to joelmartinez/GitmoSharp that referenced this issue Oct 22, 2018

Manually packing dependencies in nuget.
Requires a manual run of `dotnet restore gitmo/gitmo.csproj --packages packages` to get a releasable nuget package.
This is a workaround for NuGet/Home#3891

joelmartinez added a commit to joelmartinez/GitmoSharp that referenced this issue Oct 22, 2018

Manually packing dependencies in nuget.
Requires a manual run of `dotnet restore gitmo/gitmo.csproj --packages packages` to get a releasable nuget package.
This is a workaround for NuGet/Home#3891
@ruimsft

This comment has been minimized.

ruimsft commented Oct 24, 2018

We still didn't make this happen? It's not a good practise to make each dll as a package - we definitely need to hide some internal projects.

@chrfin

This comment has been minimized.

chrfin commented Oct 30, 2018

We where facing the same problem here and so I put together a build-script which a lot of stuff I collected from all of the workarounds for this or related problems. Combined with some of our own juice I created a package which if included creates packages similar to the "old -IncludeReferencedProjects" flag of NuGet.exe. It works fine in our internal project-/build-environment and I would like to share it, as it maybe is useful to other too: https://www.nuget.org/packages/OmicronLab.Tools.NugetTargets
I'm sure it does not work in all cases, especially as our build-system has some strange configurations, but I guess it should work in most default cases.
Feel free to extract the targets-file from the package and send me feedback/improvements. If there is enough interest I can also move it from our internal source-control to a public repository, but I hope this script is only needed for a short amount of time until there is an "official way"...

@amang2205

This comment has been minimized.

amang2205 commented Nov 1, 2018

I'm highly disappointed that this is by design.

@ericdunn

This comment has been minimized.

ericdunn commented Nov 1, 2018

It's "by design", it's just a bad design :P

@SidShetye

This comment has been minimized.

SidShetye commented Nov 1, 2018

Who is the product owner for NuGet at Microsoft? Seems we’re all just customers complaining about a bad design but this needs review from the PM/owner

@mdschweda

This comment has been minimized.

mdschweda commented Nov 6, 2018

Wait... this is intentional? 😂

@dasMulli

This comment has been minimized.

dasMulli commented Nov 6, 2018

Btw i've put together a sample recently with the latest "workaround" at https://github.com/dasMulli/AdvancedMSBuildDemos/tree/master/IncludeP2P (esp. PublicLib.csproj).

Interestingly, I've looked at the code of some folks who needed to use that and found that in many cases, the design is questionable at best.
Needing to add other projects into the package was either required because of unnecessary splitting of assemblies ("shared" code that no one else used or no layering that required it) or because some wanted to share a subset of their projects, but didn't want to manage many packages. Last one nearly resulted in problems where two packages had the same dll files packaged into them which would lead to problematic behaviour if both packages were added to a consuming project (esp. if in different versions).
I really only have seen a handful of legit use cases, but I don't claim to have seen enough to make an informed judgement. I just think that the option of being there led to a lot of "well let's add this switch and we'll be fine" without weighing in or knowing about potential drawbacks.

@ericrini

This comment has been minimized.

ericrini commented Nov 13, 2018

The design decision to drop support for using NuGet packages to encapsulate multiple assemblies is dissapointing.

@armitagemderivitec

This comment has been minimized.

armitagemderivitec commented Nov 14, 2018

This really is disappointing

@voroninp

This comment has been minimized.

voroninp commented Nov 15, 2018

@houseofcat You just don't understand the point. It's the way of coping with dll-hell: they just decided not to include dll's at all. =)

I had a faint hope .NET will be really cross platform without becoming a JVM. Alas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment