Came across this interesting post on the changes in the NCL.
http://blogs.msdn.com/ncl/archive/2009/07/20/new-ncl-features-in-net-4-0-beta-2.aspx
Tuesday, July 21, 2009
Friday, July 17, 2009
DLL HELL
Faced DLL hell issues after a real long time.
In the dev env, we compiled the VB6 dll and tested it and it worked fine.
But the minute we put it in test, it started off giving the CLSID errors.
We then registered, unregistered quite a few times. Turned out that there were multiple registrations of the same DLL. So we uninstalled all the versions, took the latest from VSS, compiled the DLL again, regsitered it and it finally worked.
Took around 2 whole days for it!!
In the dev env, we compiled the VB6 dll and tested it and it worked fine.
But the minute we put it in test, it started off giving the CLSID errors.
We then registered, unregistered quite a few times. Turned out that there were multiple registrations of the same DLL. So we uninstalled all the versions, took the latest from VSS, compiled the DLL again, regsitered it and it finally worked.
Took around 2 whole days for it!!
Monday, July 13, 2009
Tuesday, June 30, 2009
Not a valid assembly (Add Reference failure)
When trying to add a reference to a VB DLL, you may receive the following error popup: A reference to
'assemblyname.exe' could not be added. This is not a valid assembly or COM
component. Please make sure that the file is accessible, and that it is a
valid assembly or COM component.
WorkAround:-
There were some on the net, but I registered the DLL using regsvr and added it from the COM components tab and it worked fine.
'assemblyname.exe' could not be added. This is not a valid assembly or COM
component. Please make sure that the file is accessible, and that it is a
valid assembly or COM component.
WorkAround:-
There were some on the net, but I registered the DLL using regsvr and added it from the COM components tab and it worked fine.
Friday, December 05, 2008
Session on Continuous Integration
I'm planning on giving a session on Continuous Integration using CruiseControl and nAnt. Started prearing my notes for it. Hope it goes on well.
I will upload my PPT and notes if any once I'm done with it.
I will upload my PPT and notes if any once I'm done with it.
Session on Continuous Integration
I'm planning on giving a session on Continuous Integration using CruiseControl and nAnt. Started prearing my notes for it. Hope it goes on well.
I will upload my PPT and notes if any once I'm done with it.
I will upload my PPT and notes if any once I'm done with it.
Tuesday, December 02, 2008
Wednesday, November 26, 2008
Performance Tuning in ASP.NET
I have a situation here.
We have a search criteria which returns about 70K + records. We have paging and the option to export to Excel. The earlier design was using caching which I promptly got it removed. Caching is not on a per user basis. So if there are two users trying to get the same report with different search criteria, one of them is surely in for a rude shock!
I ran the perf mon and saw that the large object heap size was going in GB's. The Gen 2 heap size was also huge.
So after reading this post from Tess i came to this conclusion.
Solutions:-
Option I- Session
The primary concern is disposing the objects after usage. If we run the perfmon, we see that the data gets moved to the Gen2. This is not good. The large object heap size also goes in GB's.
Option II - Cache
This seems to be the better solution under the circumstances. The advantages of using caching is that we can set the expiry to say 20 minutes. IN order to use the cache for each user, we can use the cache key as "Session.SessionID". This will be unique for each user.
This also moves the the object to Gen2 but from what I have seen, ASP.NET takes care of disposing the cached objects as and when it faces memory issues OR "memory pressures".
Additionally in the Session End event in Global.asax, we can remove the cache item.
Option II still has some issues to be resolved.
We have a search criteria which returns about 70K + records. We have paging and the option to export to Excel. The earlier design was using caching which I promptly got it removed. Caching is not on a per user basis. So if there are two users trying to get the same report with different search criteria, one of them is surely in for a rude shock!
I ran the perf mon and saw that the large object heap size was going in GB's. The Gen 2 heap size was also huge.
So after reading this post from Tess i came to this conclusion.
Solutions:-
Option I- Session
The primary concern is disposing the objects after usage. If we run the perfmon, we see that the data gets moved to the Gen2. This is not good. The large object heap size also goes in GB's.
Option II - Cache
This seems to be the better solution under the circumstances. The advantages of using caching is that we can set the expiry to say 20 minutes. IN order to use the cache for each user, we can use the cache key as "Session.SessionID". This will be unique for each user.
This also moves the the object to Gen2 but from what I have seen, ASP.NET takes care of disposing the cached objects as and when it faces memory issues OR "memory pressures".
Additionally in the Session End event in Global.asax, we can remove the cache item.
Option II still has some issues to be resolved.
Subscribe to:
Posts (Atom)