Update GAC assembly?

Oct 21, 2013 at 7:40 PM
I have made changes to the core code to allow for two extra fields on the membership request form. I've compiled my project, but when I attempt to place it into the FBA assembly directory, the current file is already in use. How can I unlock/unload the current version of FBA to replace it with my modified one?

Reinstalling the entire solution seems a bit drastic to simply apply some rather minor code additions.

Bruce
Coordinator
Oct 21, 2013 at 7:51 PM
Reinstalling the entire solution to apply some minor code additions is unfortunately the SharePoint Way :). SharePoint deploys solutions via WSP files. I believe that part of the deploy process resets the app pool which would release locks on in use files.

If you're using Visual Studio you can deploy it directly from Visual studio.

If you just want to copy over the file (which I don't recommend), I expect that doing an iisreset will release the file.
Oct 21, 2013 at 8:10 PM
Would you recommend undeploying the original, and then deploy my customized version? Or would simply redeploying the new version over the original be sufficient? Thankfully our current environment is totally virtualized, so if it does fail I am only a snapshot away from where I began. Thanks for the help :)
Coordinator
Oct 21, 2013 at 8:42 PM
It will need to be undeployed first.

If you use the included deploy.ps1 powershell script it will undeploy then redeploy. Same thing if you do it from Visual Studio.
Oct 22, 2013 at 2:44 PM
You were correct, it was much simpler to simply deploy it from VS2012 than manually swapping out the DLLs. I do have on more question, when I attempt to run with the debugger attached, once the FBAManagement features have been activated I get a Visual Studio error stating "Object reference not set to an instance of object". This isn't an error within the FBA module, but an error within Visual Studio itself.

Clicking OK simply closes the dialog, but the debugger never attaches. The solution is still deployed successfully as well. Seems the debugger fails to attach due to the above error, but I am not sure what exactly it is referencing. Manually attaching to the w3wp process allow me to set breakpoints that turn red, but they are never hit when activating various functions within the FBA pack.
Coordinator
Oct 22, 2013 at 2:55 PM
I don't usually start the SharePoint debugging from Visual Studio because I find it really slow, and by default it undeploys the solution when I stop debugging which I usually don't want. I usually deploy through Visual Studio, open the site in the browser and navigate to what i'd like to debug, and then I attach the visual studio debugger to w3wp.exe. Note that there are likely multiple w3wp processes running, and the debugging doesn't work if you attach to all of them - you have to attach to just the one associated with the SharePoint web application you'd like to debug.

Other visual studio settings that might affect your debugging:
Turn 'Just My Code' on, so it's not also trying to debug .net framework code.
Breaking on exceptions: only break on unhandled exceptions.
Oct 22, 2013 at 9:19 PM
I never managed to get live debugging working, but writing to the Event Log got me what I needed. I successfully added Company and Phone# fields to the User request form that appear on the Request List.

I have learned volumes about SharePoint coding and ASP in general thanks to your awesome library. Thanks for all of your help and this great library!
Bruce