ReferenceSource: https://github.com/Microsoft/referencesource/tree/master/ has missing source code (mostly internal types). We should publish them.
@richlander can you point me to the process?
@marek-safar @akoeplinger do you have list of other missing pieces from ReferenceSource?
cc @danmosemsft
@karelz should we move this issue to referencesource tree? why we are opening it here?
The repo does not allow issues to be opened :( ... I tried ;-)
interesting :-) thanks for checking.
Here's list of missing things from @marek-safar
mscorlib
- Missing class PathInternal
System
- Missing class SRCategoryAttribute
System.ComponentModel.DataAnnotations
- Incomplete System.ComponentModel.DataAnnotations.txt (missing ~45 entries)
System.Data
- Missing enum PoolBlockingPeriod
- Missing class SNINativeMethodWrapper
- Missing class ResCategoryAttribute
- Missing class ResDescriptionAttribute
- Incomplete system.data.txt (missing ~120 entries)
System.Data.Entity
- Missing class EntityResCategoryAttribute
- Missing class EntityResDescriptionAttribute
- Missing class EntityRes
- Incomplete class Error
System.Core
- Missing Error class
- Missing Strings class
- Incomplete System.Core.txt (missing ~26 entries)
System.Web.ApplicationServices
- No System.Web.ApplicationServices.txt resources file
System.Web.Services
- No System.Web.Services.txt resources file
System.Runtime.Caching
- Missing class ExpiresEntryRef
- Missing class CacheExpires
- Missing class UsageEntryRef
- Missing class CacheUsage
- No System.Runtime.Caching.txt resouces file
System.Runtime.Serialization
- Incomplete System.Runtime.Serialization.txt
@preetikr
@preetikr when you think this will get done?
@preetikr any update here?
Sent internal mail to get it started.
This isn't related to 2.0. Moving to future.
It needs to happen in 2.0 time-frame, we have been sitting on it for way too long for no good reasons. I'll mark it Post-ZBB.
It needs to happen in 2.0 time-frame
That's fine, but it has nothing specific to do with CoreFx nor 2.0. Why aren't we tracking this in TFS for example, where other desktop-related issues are tracked?
Fair point. I'd keep it in CoreFX mostly for simplicity. This affects our partners (Xamarin), around their ability to share CoreFX sources, etc.
I fear if we move it elsewhere, no one will pay attention to it (again). If you know about place which is monitored by someone (who says so), happy to move it there ...
@karelz if you open TFS bug against 4.7.1 this should be tracked and cared
Right. Tracking it here makes little sense to me.
I fear it will just be pushed to future as non-blocking thing for 4.7.1 (I've seen it way too many times ;))
I guess if @marek-safar and @akoeplinger are fine with checking on the bug in internal TFS db, we can move it there ...
I don't care where it's tracked as long as it gets done :)
I fear it will just be pushed to future as non-blocking thing for 4.7.1 (I've seen it way too many times ;))
A fine fear. But we can't use the corefx repo as a dumping ground for completely corefx-unrelated issues just because we fear folks won't be looking in the right place.
(Maybe I should start using issues in the corefx repo as a place to track my grocery shopping list as I spend so much time in the corefx repo and I'm concerned I won't pay as much attention to the note on my fridge. :wink:)
Nice comment 馃槢
I hear ya. The situation here is different - Mono/Xamarin folks have been asking for this for years AFAIK. And we didn't act. So I guess it is time to create pressure on ourselves as well ;)
@preetikr can you please chime in if we are on track and where best to track the issue? Given that Mono/Xamarin folks are ok to track it internally, I am fine moving it into internal 4.7.1 db or something like that ...
The situation here is different
I disagree. If someone from company XYZ created a 2.0 issue in the corefx repo for something unrelated to corefx and unrelated to the 2.0 release, regardless of history, you would immediately close the issue, tell them it is inappropriate, and ask them to track it elsewhere. I don't see how this is any different.
I'll stop commenting on this now.
I think we can just move this to TFS and close this one.
I agree with stephentoub on the .NET Framework issue being tracked here. You can share your feedback on .NET Framework aspects including Reference sources @ https://github.com/Microsoft/dotnet/issues
That said this issue is resolved and .NET Framework 4.7 reference sources to include the following have been published @ https://github.com/Microsoft/referencesource - Missing ones are intermediate files those are either not available in .NET Framework build process or are .NET Core files and not .NET Framework files.
- Missing class PathInternal in mscorlib
- Missing class SRCategoryAttribute in System
- Incomplete System.ComponentModel.DataAnnotations.txt (missing ~45 entries) in System.ComponentModel.DataAnnotations
- Missing enum PoolBlockingPeriod in System.Data
- Incomplete system.data.txt (missing ~120 entries) in System.Data
- Incomplete class Error in System.Data.Entity
- Missing Error class in System.Core(Published as ErrorCode.cs)
- Incomplete System.Core.txt (missing ~26 entries) in System.Core
- No System.Web.ApplicationServices.txt resources file in System.Web.ApplicationServices
- No System.Web.Services.txt resources file in System.Web.Services
- Missing class ExpiresEntryRef in System.Runtime.Caching
- Missing class CacheExpires in System.Runtime.Caching
- Missing class UsageEntryRef in System.Runtime.Caching
- Missing class CacheUsage in System.Runtime.Caching
- No System.Runtime.Caching.txt resouces file in System.Runtime.Caching
- Incomplete System.Runtime.Serialization.txt in System.Runtime.Serialization
Most helpful comment
I think we can just move this to TFS and close this one.