I have a C# PCL project that uses code contracts. However on TeamCity the project fails to build, but it looked like the build was successful locally. However the build log does claim that the build did fail, but it gives no reason at all.
'Fail build on warnings' is disabled.
I get a single strange warning:
CodeContracts: Could not find the method/type
'System.Diagnostics.Contracts.PureAttribute' in assembly '[project
path]\packages\Microsoft.Net.Http.2.2.29\lib\portable-net40+sl4+win8+wp71+wpa81\System.Net.Http.dll'
Searching google gave me one relevant result with someone who has the same problem.
However it has no responses besides bumping.
Build log
I also find this line peculiar:
C:\Windows\system32******.dll (1,1): message : CodeContracts: Checked 3154
assertions: 2821 correct (333 masked)
Why is the binary located in system32? I didn't think MSBuild even had write access to that folder...
The issue seems to be that it by default looks for contract types in Microsoft.Contracts (per spec) which doesn't work because Microsoft.Contracts is not what I am using. I'm using System.Diagnostics.Contracts, which is located in mscorlib. It doesn't tell me this, rather it does something non-sensical. I started looking through the source code and I found the offending code but in my opinion this code is of poor quality, so I gave up on actually finding the issue and creating a pull request.
However the solution is simple when you know: you need to override the default for the contract library which is Microsoft.Contracts with mscorlib, so simply add the following to the command line of the static analyzer:
-cclib mscorlib
This worked for me at least. I still think this is caused by two bugs in Code Contracts:
It fails the build because of a warning.
It tries to locate the PureAttribute in the wrong assembly.
Related
We have some dynamic C# code that is compiled and executed at runtime.
Both for versioning (TFS) as well as to find possible syntax errors, intellisense, etc. we have the code in our main solution.
This code should not be in the generated assembly though since it might contain data that is not to be distributed.
Is there any way to get the desired behavior of having it in each compile and also not having it in the generated output?
We do have a TFS-based build system, though it would be good to also have this feature for local compiles on each developer's machine.
I have a project I'm trying to run in android, it's giving me this error. I was just messing around for 2 minutes trying the following:
someEntry.BackgroundColor = Color.Green;
After this my app crashed while it was working before.
EDIT: I am aware that this had nothing to do with it but I was desperate to find out what was going on which is why I put this in the explanation.
I undid all my changes afterwards. Ever since I did that this error occurs on startup:
Unhandled Exception:
System.TypeLoadException: Could not resolve type with token 0100004c
So I guess my question mostly is, what does this token "0100004c" mean and is there any way to fix it?
Thanks in advance.
Errors like this usually mean that the assemblies aren't in sync any more. This means that assemblies, gathered in your bin and obj folders in the different projects contains mixed versions and thus can cause unexpected behavior. This is already detected while loading and gives a bit cryptic error message, like the one you are seeing.
There are basically two options to resolve this quickly:
Try a clean and rebuild on your complete solution
If that doesn't work; manually delete the bin and obj folders from each project folder and rebuild
The exact cause for this is hard to say. Hopefully it was just an incident and from here on out you will be fine. If it happens more often, you probably want to look into the order that your projects are built within your solution and what projects are built when you run your executable project. It could happen that a project is built to late, or not being rebuilt at all when running from the IDE.
Looking through Roslyn's documentation, I could not find anything about failing the build. I have currently built an analyzer tool that will look to see if methods are missing a tag and notify the developer with a suggestion to add this tag. But what I want to do is be able to fail the build if they attempt to build the project.
I saw places online where devs have been using: CodeIssue but I do not think this would work.
This would be similar to how stylecop works when it fails the build.
Has anyone found any examples/resources where it can return a build failed with errors?
You can set the compiler options to treat your analyzer's warning ID as an error, just like with built-in warnings.
When I try to install IronPython on Debian with Mono (3.12), I get the following error:
socket.cs(1900,63): error CS0117: `System.Net.Sockets.SocketOptionName' does not contain a definition for `IPv6Only'
How can I solve this problem? According to the IronPython website, everything should compile without errors.
In the Mono mailing list there is already such a bug, but there is no answer to this bug. Therefore I thought that maybe this forum is a better place for this question.
I'm no expert on either IronPython or Mono, but out of curiosity I just tried this.
For whatever reason, the IPV6Only value in the SocketOptionName enum appears to be missing in the Mono implementation. The error message you're getting is from the code in IronPython.Module/Socket.cs attempting to reference this. It turns out that this is already recognised in the codebase as a feature that not all platforms have, so there's an easy workaround:
The Common.proj project file in the Solutions/ directory in your git checkout defines a number of possible ReferencedPlatform values. The default value is V4. Just below there in the XML, find a block starting:
<PropertyGroup Condition="'$(ReferencedPlatform)' == 'V4'">
Nested in there is a Features element with a list of the features that apply, and if you find and delete FEATURE_IPV6 at the end of the list, then you should find that the project will build using make. I briefly tried firing up the ipy.exe that is generated and it seems to work.
Obviously this isn't a very good solution. Probably the best thing would be to file a bug report with the IronPython project. I guess that Mono on Linux is probably a fairly low priority for the guys who are working to maintain it.
Correct, up to mono 4.0 throws Protocol option not supported when setting IPv6Only false.
This is probably resolved here: https://github.com/mono/mono/blob/mono-4.2.0-branch/mono/metadata/socket-io.c#L536
But do note the compile flag IPV6_V6ONLY
I have installed SwaggerUI for .Net from Nuget package and trying to test web api methods with the swagger. But I am get below compile time error.
Error Assembly generation failed -- Referenced assembly 'WebActivator' does not have a strong name
When I change the solution settings for signing property from checked to unchecked I don't get this error. Now I don't want to change any settings that are made to signing property of solution settings and fix this error.Can any one please help me to fix this error?
Your assemblies are strong named while the new assemblies you referenced recently are not. And more than this, they are not compiled from source (you got them via NuGet).
Two workarounds cross my mind now:
Get the sources for SwaggerUI and dependecies and sign them with your key. I think this is a tedious process, since you need to build everything.
Use the DLLs like now and sign them after each build. For example you can use these instructions (dissasemble, sign & re-assemble). If you do this, I think it's worth adding this as a pre-build step to your least-dependent project (the one that builds first).
I have also found this - Assembly Strong Naming Toolkit (for NuGet). Never tried, but maybe it's worth looking into as it seems to be designed for your case.