"Invalid token ',' in class, struct, or interface" after checkout

Answer 1

I guess the original error message meant you had a malformed C# expression in

return ((EPiServer.Personalization.SubscriptionInfo, EPiServer)...

nothing to do with the config file.

Probably you typed "," instead of "." ? (As the compiler reads this, you provide 2 types in the cast)

Revert web.config to its original version and fix the typo, that should work.

update after Greg's comment:

I didn't realize the config section you posted were part of the EPIServer configuration. You were right then to remove the assembly names.

However I guess you need to reference the EPiServer from the web app (Add Reference...). I think I noticed this in my projects too: If you checkout an ASP.Net app to a new location, you need to add all references again.

Answer 2

Have you tried referencing the EPiServer assembly correctly?

I assume that it's displaying ok in the project references node in the Solution Explorer, and hasn't got a yellow exclaim overlay on it?

Perhaps you could reference it in the web.config compilation section as well:

<compilation debug="false">
  <assemblies>
    [...]
    <add assembly="Episerver, Version=5.2.372.7"/>
  </assemblies>
</compilation>

You may either not need the version number, or you may need to add the version number and culture type - there should be a few other assemblies referenced in there already for reference.

You could also try:

<add assembly="EPiServer" />

and other variations.

---

Sounds like an Assembly Load issue then:

Check that the EPiServer DLL is accessable in your new location - is it installed to your computers Global Assembly Cache, or is it a local reference to the /bin folder? Is the dll in the bin folder? Is the dll included in source control?

Answer 3

You're trying to cast to (EPiServer.Personalization.SubscriptionInfo, EPiServer) which is invalid syntax, that's why it's complaining about the comma.

Simply remove the ", EPiServer" part and cast like this: (EPiServer.Personalization.SubscriptionInfo)

I guess someone accidentally checked in a non-buildable change into SVN! ;)

Answer 4

I ran into this several times and done it for me is when I manually copied the EPiServer assemblies to the bin folder. That works for sure but it's not very elegant. Zhaph's solution with the assemblies tag looks much nicer I'll try it next time.

Answer 5

It's been a while since I asked this and I keep looking thinking that I need to remember what the issue was and post the answer. I think this is it.

It turned out that there was an issue with application finding the DLLs that EPiServer installed. I'm not sure exactly and I'll update this post once I get chance to try it out on a clean machine, I'm still mid-project so it's not a very good time to be faffing about.

The way I fixed it was to get the DLLs from c:\Program Files\EPiServer\CMS\VERSION\bin and put them in the bin folder for the application.

Once I get chance to do a clean install somewhere I'll see if it is infact the project (which I doubt) or, more likely, the installation on my computer which is broken.

Answer 6

Hi,

I just had a similar problem this afternoon. The problem was that the EpiServer dlls were not present in the bin directory of the website, so I got bind failures.

The project had been created by one of my colleagues and the relevant EpiServer dlls were added as solution items in a lib folder and referenced from there. However, as he had initially created it from the EpiServer project template, the libraries had automatically been added to the bin folder also. When he updated the references to point to the lib folder, copy local defaulted to false. This still worked on his machine due to the original copies placed in the bin folder by the template. Updating them to CopyLocal = True fixed the issue.

Answer 7

I just had this same problem, again with an EPiServer site. It was because I was referencing the EPiServer DLLs, but they did not have the "copy to local" property set to true on all the references, and so they were not all being placed in the bin directory.

Answer 8

I encountered this problem as I was restructuring the dll references in a project.

I had moved the external/third part dlls from the bin folder to a library folder outside the web project root.

My problem was that some of the dll references did not have copy local set to true, so they were never copied to the bin folder on build.