CSC : error CS7038: Failed to emit module #4196
Assignees
Labels
Area-Compilers
Bug
Tenet-Compatibility
Violation of forwards/backwards compatibility in a design-time piece.
Milestone
Comments
|
As was already mentioned on Stack Overflow you need to provide enough information for people to replicate your issue. Without that, I think it's unlikely anyone will be able to help you. |
gafter
added
Area-Compilers
Need More Info
|
I think I'm seeing the same problem. I've managed to isolate the issue below, unfortunately can currently only reproduce using a Third Party library which I'm unable to share freely, will continue working to try and recreate or get permission to share with you privately. For me the issue occurs when calling a method on an interface which has two overrides defined, one accepting just an int, the other accepting a Guid and an object with a default value. For example: public interface IRepository
{
Item Get(Guid contentId);
Item Get(int threadId, ItemGetOptions options = null);
}Class names altered to make less specific to third party domain, other methods removed for brevity From a new Class Library project named FailedToEmitModuleExample, using .NET Framework 4.5, I've created a class like so: public class Tester
{
private readonly IRepository _repository;
public void DoSomething()
{
var result = _repository.Get(123);
}
}This fails to build giving the following error message: This only occurs in Visual Studio 2015 RTM (14.0.23107.0 D14REL). The same project builds correctly in Visual Studio 2015 RC (14.0.22823.1 D14REL) and Visual Studio 2013 (12.0.31101.00 Update 4). With Diagnostic logging enabled for MSBuild this is the Output snippet for the CSC task: Third Party DLL Name Changed Interestingly the following compiles (replacing the int argument with a Guid): public class Tester
{
private readonly IForumThreads _repository;
public void DoSomething()
{
var result = _repository.Get(Guid.Empty);
}
}Also, calling other methods with overloads on the interface compiles correctly: public interface IRepository
{
Item Get(Guid contentId);
Item Get(int threadId, ItemGetOptions options = null);
PagedList<Item> List();
PagedList<Item> List(ListOptions options);
}Class names altered to make less specific to third party domain, other methods removed for brevity public class Tester
{
private readonly IForumThreads _repository;
public void DoSomething()
{
var result = _repository.List();
}
}Hope this makes sense. Let me know if there is any other information that would be useful and I'll continue looking at a standalone recreation of this issue. |
Is this third party library obfuscated? According to this answer on StackOverflow, the problem might be related to obfuscation. |
|
Yes the DLL being referenced is obfuscated using Smart Assembly, would suggest that it is the culprit. Unfortunately I can't (and imagine others who run into this) can't upgrade SmartAssembly and rebuild as I don't have the source :) |
|
We use Smart Assembly also. And I have problems with parameters with default values. After an upgrade to SmartAssembly 6.9 the problem is gone. |
gafter
added
Resolution-Answered
|
Closing as you appear to have found the source of the issue. |
|
Hi @gafter, I have confirmed this is fixed by using Smart Assembly 6.9, this example solution shows an example. Not sure how wide ranging this issue is (pretty specific set of circumstances), but would have thought in most cases where an assembly is obfuscated, it would have been provided by a third party vendor, rather than the user experiencing the problem, so fixing may not be as simple as just upgrading SmartAssembly, but rather liaising with the vendor and getting a fix from them. I'm currently speaking to the vendor we are experiencing this issue with. Thanks, Rhys |
jaredpar
added
Bug
Tenet-Compatibility
|
This is a duplicate of internal bug 1203205 |
jaredpar
added a commit
to jaredpar/roslyn
that referenced
this issue
Aug 28, 2015
The native compiler handled corrupted default parameter values by substituting in default(T). It's unclear if this was intentional behavior in the compiler or not. Either way though obfuscators took advantage of this behavior and at least one prominent one will corrupt default parameter values when the value is null. Enough prominent libraries have shipped using such obfuscators that it is a blocker to upgrading. Hence we need to emulate the native compiler behavior here. This change is a bit large because I needed to update the test resources with a corrupted DLL in order to test out the changes. closes dotnet#4196
|
Is there any indication on when and how this fix will be released? Will it be in a VS 2015 update 1? It's preventing one of our projects from being compiled in VS 2015. Thanks, |
|
@KallDrexx this fix will be a part of VS 2015 update 1. If you'd like to unblock a single project which is affected by this bug then you can do the following:
After that build in VS 2015 should succeed. What this command is doing is simply patching the csc used to compile that specific project with the version packaged in Microsoft.Net.Compilers. This is a build between VS 2015 RTM and Update 1 which includes this fix. This is a non-RTM build though so the usual beta software caveats apply. But it's also the version we are using to compile Roslyn right now in our repo (we apply the patch to every project) so it's fairly stable. |
|
Very much appreciated, thank you! |
|
Hi @jaredpar, I've tried adding the nuget package to the example repository I linked to earlier, but I'm still getting the same error. I've tried closing the solution/vs, but it doesn't make any difference. Any idea what I might be missing? |
|
@rhysgodfrey I just tried this on that repo and I was able to work around the build error. Here is a commit which demonstrates the changes that came from running the NuGet install on the project. Can you compare it to what you are seeing locally? Couple of items to note:
BTW: really appreciate you going through the time to make that repo to demo the problem. Made it super easy to validate for us 😄 |
|
No worries, anything to make it easier :) Apologies for leaving the old references in. I've just tried again with your branch and still getting the error :( Using Sorry for being a pain! Any idea what I could be missing? |
|
@rhysgodfrey interesting. I'm looking into that. |
|
@rhysgodfrey I tracked down the disconnect. There was an error on my side that caused me to think I was using the latest NuGet package for the compiler, when in fact I was using the latest build on my machine. The fix for this issue is not in the latest NuGet package:
The timing caused this fix to just miss the toolset snap. The good news is that it will definitely be in the next toolset which will be published in the very near future. Our goal cadence for toolsets is every three weeks. We've just gotten a bit behind this time due to other issues. |
|
@jaredpar cool, will keep an eye out for the next release. Thanks for your help! |
|
I'm seeing this CSC error CS7038 too. Thanks! |
|
@josesimoes unfortunately there isn't really any verbose output that is going to help here. This error generally comes from an exception inside the compiler during the emit phase. The best way to get more detailed information is to attach a debugger and see where the exception is coming from. Do you have a solution available that reproduces the problem that I could look at? |
|
@jaredpar thank you for the prompt reply. |
|
@josesimoes assuming you're building from MSBuild. In that case
There will probably be a few cancellation exception thrown and those can be ignored. What we're looking for is an exception that is thrown while Emit is further up on the stack. When that happens can you post the exception info + the stack trace. Also feel free to email me with the information if you'd prefer to keep it off github. (jaredpar@microsoft.com). |
|
@jaredpar just tried this out with the VS2015 Update 1 CTP and everything is building happily. Thanks for your help! |
|
@jaredpar to update you on this:
Thanks for your help and sorry for taking so long to get back to this matter. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After installing Visual Studio 2015 and building my project I receive the error "CSC : error CS7038: Failed to emit module".
However my solution is building fine in Visual Studio 2013.
ASP.NET webforms project in .NET 4.0
The text was updated successfully, but these errors were encountered: