- 11 8月, 2016 1 次提交
-
-
由 Tomáš Matoušek 提交于
-
- 18 5月, 2016 1 次提交
-
-
由 Tomáš Matoušek 提交于
-
- 17 5月, 2016 1 次提交
-
-
由 Evan Hauck 提交于
-
- 27 2月, 2016 2 次提交
-
-
由 Andy Gocke 提交于
Right now there are two code paths for signing using a keyfile: 1) Full & delay signing implemented using a strong-name provider, which calls into the CLR when necessary to do signing. 2) Public signing, which extracts the key directly from the file and embeds it manually into the assembly using only portable code. The tricky part is that (1) also implements a bunch of legacy semantics on how to resolve the key file from various search paths, since the key file can also be specified via an attribute. This behavior is already deprecated, so rather than implement the complicated file resolution for public sign as well, this PR changes the command line compilers to always produce an absolute path for the key file before passing it to CompilationOptions. CreateCompilation now also has a check to enforce that CryptoKeyFile is an absolute path when PublicSign is set. Fixes #8360.
-
由 Tomas Matousek 提交于
-
- 25 2月, 2016 1 次提交
-
-
由 Ty Overby 提交于
-
- 02 2月, 2016 1 次提交
-
-
由 AlekseyTs 提交于
Fixes #8287.
-
- 16 11月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
-
- 14 11月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
Sometimes called "fake sign" or "OSS sign" public signing is including the public key in an output assembly and setting the "signed" flag, but not actually signing the assembly with a private key. This is useful for open source projects where people want to build assemblies which are compatible with the released "fully signed" assemblies, but don't have access to the private key used to sign the assemblies. Since almost no consumers actually need to check if the assembly is fully signed, these publicly built assemblies are useable in almost every scenario that the fully signed one would be used in. This PR implements support only for C# -- VB will be added soon. If being used at the command line, the /publicsign flag can be passed to csc and the /keyfile flag can specify the public key. Unlike fully signing, a full key pair encoded in the SNK file format is not currently supported. When using /publicsign, just the public key must be in the /keyfile file. When using the API, the public key can be passed directly using the CryptoPublicKey CompilationOption.
-
- 04 11月, 2015 1 次提交
-
-
由 Neal Gafter 提交于
-
- 29 10月, 2015 1 次提交
-
-
由 Ty Overby 提交于
Previously, the unix root "/" would not be considered a valid path for pathmap to map to. This commit fixes that, adds a test case, and adds diagnostics for unparsable pathmaps.
-
- 16 10月, 2015 1 次提交
-
-
由 Paul Harrington 提交于
-
- 27 8月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 12 8月, 2015 2 次提交
-
-
由 Tomas Matousek 提交于
-
由 Tomas Matousek 提交于
-
- 18 3月, 2015 1 次提交
-
-
由 mavasani 提交于
Add a new switch '/errorlog:' to VB and C# command line compilers to log all the compiler diagnostics into a log file. Add command line parsing tests and error log content validation tests.
-
- 06 3月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
Enable hosts to compile strong-named assemblies on all platforms by supplying public key via compilation options and also enable OSS signing with such key
-
- 15 1月, 2015 1 次提交
-
-
由 jaredpar 提交于
-
- 14 1月, 2015 1 次提交
-
-
由 RoslynTeam 提交于
-
- 24 12月, 2014 1 次提交
-
-
由 TomasMatousek 提交于
Due to CLR bug 1094313 the added members can't be referenced from another assembly. For now we report a rude edit if we detect a MemberRef or TypeRef to a symbol added during debugging. (changeset 1384081)
-
- 04 12月, 2014 1 次提交
-
-
由 srivatsn 提交于
When we crack open an analyzer dll and instantiate analyzers, we can produce some warnings in faulty cases. These were being produced way to early and weren't being passed through regular filtering code. Such support didnt exist because we were only producing errors during this stage. We don't want these warnings to be errors. Adding some code to call into the CSharp\VBDiagnosticFilter type which has all the filtering logic based on options. There were already a bunch of unit tests for this scenario - all recording the errant behavior. fixing them all up now. (changeset 1378577)
-
- 07 10月, 2014 1 次提交
-
-
由 TomasMatousek 提交于
Moves options that were previously on CompilationOptions but were not used until emit phase to EmitOptions: fileAlignment, baseAddress, highEntropyVirtualAddressSpace, subsystemVersion, runtimeMetadataVersion. They hold on values written to various PE headers. We can now easily add other similar PE flags to EmitOptions, which is a common customer request, without affecting code that works with compilation options in other layers (workspaces, project system, etc.). Removes EmitMeadataOnly method and instead adds a MetadataOnly flag to EmitOptions. Removes MetadataOnlyEmitOptions - they were not used and can now be easily added as bools to EmitOptions. Moves pdbFilePath and outputName from parameters of Emit to EmitOptions. IDE: remove tracking of options that were moved to EmitOptions, since the IDE doesn't care about options that don't affect compilation. (changeset 1348623)
-
- 20 6月, 2014 2 次提交
-
-
由 manishv 提交于
Address CR feedback for changeset 1272615 (Handle analyzer type load failures in a better way): Change the newly added diagnostic's severity to be an info rather than a warning. (changeset 1272711)
-
由 manishv 提交于
Handle analyzer type load failures in a better way: If Assembly.LoadFrom throws a ReflectionTypeLoadException, our current behavior is to log a compiler warning and skip the analyzer assembly. However, this exception might be caused by some unrelated missing types in referenced assemblies and it is possible to continue looking for analyzers from the loaded types in the assembly. This change tweaks the behavior to now log a separate warning for a ReflectionTypeLoadException, and continues working with only the loaded types. (changeset 1272615)
-
- 20 3月, 2014 1 次提交
-
-
由 TomasMatousek 提交于
Replaces FileResolver with 2 types that are portable and implement reference resolution for specific feature. The goal is to have 3 resolvers total - one for each kind of reference to artifact that the source may contain 1) MetadataReferenceResolver Resolves #r directive values. 2) SourceReferenceResolver Resolves source references and normalizes source paths. Used by #line, #pragma checksum and PDB paths (and #load in script files, which is not implemented yet). 3) XmlReferenceResolver Resolves references to XML documents in <include> and PermissionSet(File = "...") Each resolver is also a provider of the resolved content. Currently that's not true for MetadataReferenceResolver, we have a separate MetadataReferenceProvider. I'll follow up with a change that merges these two. In addition to the above resolvers CompilationOptions still have AssemblyIdentityComparer and StrongNameProvider. These remain unchanged. The non-portable part of the compiler provides a file resolver for each reference resolver: 1) MetadataFileReferenceResolver (to be renamed to MetadataFileResolver) 2) SourceFileResolver 3) XmlFileResolver these resolvers implement csc/vbc behaviors. Default CompilationOptions don't have any resolvers. Thus the features that are dependent on these resolvers won't work and a diagnostic is reported. (changeset 1208519)
-
- 19 3月, 2014 1 次提交
-
-
由 Pilchie 提交于
-