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
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.
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 :)
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.
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.
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.
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