aspnet_compiler looking for jsharp code provider on a C# mvc2 application

Question

I am compiling an MVC2 application in Visual Studio 2010 on Windows 7 64-bit. I am running the following as a post-build event command:

aspnet_compiler.exe -v / -p \

It results in the following error:-

The CodeDom provider type "Microsoft.VJSharp.VJSharpCodeProvider, VJSharpCodeProvider, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" could not be located

I have no J# in my solution. I've downloaded the J# 2.0 redistributable package Second Edition, but that didn't help.

The funny thing is, I ran this in a BRAND NEW MVC2 solution and got the same error! So it has nothing to do with my application.

What am I missing that's causing this error?

I have read many other posts that say you need to install the redistributable, add a reference in web.config etc. but they didn't help.

Any ideas??

Answer 1

@Kyralessa : I was having the exact same error. Adding the Administrators role to the user under which the website was running "fixed" the problem but as you said it is not an ideal solution.

So I was fiddling around with IIS settings and under the Basic settings of the website I switched to "Application user (pass-through authentication)" and the problem disappeared. The app pool still runs under the same (non-admin) user so there is no security issue.

Answer 2

Try installing one of the packages below:

32-bit: http://www.microsoft.com/download/en/details.aspx?id=18084

64-bit: http://www.microsoft.com/download/en/confirmation.aspx?id=15468

This got me past the error when none of the other solutions would work.

Answer 3

I was having this same error when I set MvcBuildViews property in the csproj to true. After much research and trial/error, I learned that the problem was because our site had .java files in the site's structure. These java files were not a part of the solution, simply loose files. The Aspnetcompiler task runs from the project root, so it finds all kinds of issues like duplicate web.configs and *.java files.

To deal with this, I created the following target in the MVC project file I was trying to debug:

<Target Name="MvcBuildViews" AfterTargets="Build" Condition="'$(MvcBuildViews)'=='true'">
   <!-- This task performs compilation of the CSHTML files in the web structure 
   and will generate compiler errors if there are issues in the views, such as missing
   resource strings, broken class locations, etc.
   Due to an issue with the AspNetCompiler task identifing .java files as candidates for
   compilation, we will temporarily rename all of the java files in the project to .xyz
   so they are skipped by aspnet compiler. Then we rename them back. 
   Extra web.configs also cause an error, so those are temporarily moved. -->
   <CreateItem Include="$(ProjectDir)**\*.java">
      <Output TaskParameter="Include" ItemName="JavaFolderA"/>
   </CreateItem>
   <CreateItem Include="$(ProjectDir)obj\**\web.config">
      <Output TaskParameter="Include" ItemName="ExtraWebConfigsA"/>
   </CreateItem>    
   <Move SourceFiles="@(JavaFolderA)" DestinationFiles="@(JavaFolderA->'$(ProjectDir)%(RecursiveDir)%(FileName).xyz')"/>
   <Move SourceFiles="@(ExtraWebConfigsA)" DestinationFiles="@(ExtraWebConfigsA->'$(ProjectDir)%(RecursiveDir)%(FileName).ccc')"/>

   <AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />

   <CreateItem Include="$(ProjectDir)**\*.xyz">
      <Output TaskParameter="Include" ItemName="JavaFolderB"/>
   </CreateItem>
   <CreateItem Include="$(ProjectDir)obj\**\web.ccc">
      <Output TaskParameter="Include" ItemName="ExtraWebConfigsB"/>
   </CreateItem>
   <Move SourceFiles="@(JavaFolderB)" DestinationFiles="@(JavaFolderB->'$(ProjectDir)%(RecursiveDir)%(FileName).java')"/>
   <Move SourceFiles="@(ExtraWebConfigsB)" DestinationFiles="@(ExtraWebConfigsB->'$(ProjectDir)%(RecursiveDir)%(FileName).config')"/>
</Target>

Hope this saves someone the 3 hours it took me to figure out...

Update: Because this does add more time to the build, you may choose to add to the condition at the top to only perform this check during Release style builds:

<Target Name="MvcBuildViews" AfterTargets="Build" Condition="'$(MvcBuildViews)'=='true' AND '$(Configuration)' == 'Release'">

Answer 4

@Adrian - I had this problem today and fixed it nearly straight away, it was trying to compile J# in a C# project, weird error. But the problem was I copied a .java file into my project folder and the issue occured. Once I removed that, it all compiled again fine.

Answer 5

I had this happen today, and found a solution of sorts.

I'm using VS 2010 and an ASP.NET MVC 3 site, using Razor, running in IIS (not IIS Express or Cassini).

In my case this error cropped up in my .cshtml views. For any view I opened, the first @using line was underscored with the error:

C:\PathToMyCode\PathToMyViews\Index.cshtml: ASP.NET runtime error: Could not load file or assembly 'VJSharpCodeProvider, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. An error relating to security occurred. (Exception from HRESULT: 0x8013150A)

There were also bizarre errors throughout the page, such as ambiguous references between two assemblies with the same name (e.g. a supposedly conflict between "System.Web.Helpers" and "System.Web.Helpers").

The cause: I was running the web site under a user account that didn't have sufficient permissions. The account had the IIS_IUSRS role, but apparently there's some other role or access it needs to make this work, or it may need access to a particular folder it couldn't get to.

Unfortunately, I don't know what it is, and I'm not excited about the idea of wasting hours to figure it out after I already spent way too much time trying to figure out how this happened in the first place.

But giving that user the Administrators role resolved the error.

I realize this isn't an ideal solution, but I hope at least it gets some people unstuck. If anyone figures out exactly what permissions are necessary to prevent this error, comment below and perhaps we can narrow it down.