0

I have this weird problem, this is the set up.

I have a class library written in VB. The dll is signed and deployed to the GAC. The dll is a wrapper around the Session object, to store the current user in. The session is store in db, not in memory. I have multiple Web Sites written in VB, consuming this dll without any problem.

Now that we're switching to c#, I added a new Web Site project in c# and added a reference to the same GAC'd dll project.

Now, when I use the VB ddl classes in the c# web site, it seems as if the C# web site is using another Session/Copy of the dll ?

So my question is, Is it possible to use this setup? Is it possible that the VB GAC dll has a 'VB and a C# version' ? Should the VB websites and the C# website be using the same dll?

UPDATE: I checked the SessionID and indeed, there is a different SessionID in the VB websites, and the C# Websites. Altho both sites are running in the same Application pool and using the same Session Settings (Store In Database)

Hope I'm clear enough, will provide more info if needed!

stvn
  • 1,148
  • 1
  • 8
  • 24

1 Answers1

0

Both: c# and vb.net are compiled to same MSIL... doesn't matter what language you have used

Try:

  1. Delete TMP files: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\ (your app folder). Stop appPool before!
  2. If is your DLL in GAC, shouldn't be in BIN folder of your web site (check it). Check if you don't have set "Copy Local" to true in your DLL reference properties
Tomino
  • 5,969
  • 6
  • 38
  • 50
  • any idea how to disable this in a Web Site project? I'm not using the Web Application template ( legacy ) – stvn Oct 04 '12 at 08:13
  • answer here: http://stackoverflow.com/questions/2059118/reference-dlls-in-asp-net-without-bin-or-gac – Tomino Oct 04 '12 at 08:20
  • tried everything you suggested. Not working. All sites run as applications under a single site/application pool but for some reason, the C# website generates another Session ID than the VB Websites?? – stvn Oct 04 '12 at 09:17
  • It't hard to say, because nobody knows what your VB DLL really does. The answer to your first question is: It doesn't matter if is assembly written in C# or VB, because both are translated into MSIL. – Tomino Oct 12 '12 at 12:01