I was recently trying to write a message to MSMQ on a remote server. I knew there were two steps but I didn't realize there was a third.
1. Modify the Queue name to the correct format
2. On the MSMQ queue give write access to the account you are running under
3. Install MSMQ on the source server
MSMQ name
The MSMQ format name is a particular structure you need to get right - including the case:
FormatName:DIRECT=OS:<servername>\private$\<queuename>
Write Access
If your code was running as a web service as mine was, then the App Pool identity must be a domain account and that account needs to have write access to the MSMQ on the target server.
Install MSMQ locally
I hadn't relaized this. You must install MSMQ in the local server where the code is running. The reason is that it logs messages in an Outbound Queue. This is what you would need if you were running in an off-line situation and then wanted the messages forwarded when you were on-line. I did not relaize that it would also do this even with a permanently connected enviroment. So install MSMQ locally and life will be good.
Sunday, July 18, 2010
InfoPath 2007 and Forms Services - Deployment
I've always hated deploying InfpPath forms to a Production environment because I couldn't figure out how to change the path of any data connections without modifying the data connections with the appropriate url which means installing InfoPath in a Production environment.
I recently found that with an InfoPath form with managed code you can modify the manifest.xsf manually in NotePad and modify any urls. Publishing the form from VS will then create an XSN with the correct urls. This avoids using the data connection wizrd which will try to access the url.
Now I already new that you can convert the data connections into a UDCX file and then store that in a local data connections library but the path to the data connections library was still hard coded in the XSN with the server name. So if you deploy to production the InfoPath form is looking for the data connection library you used in development. It seemed like a ridiculous situation.
But finally I stumbled on this post which explains what to do. The post deploys the InfoPath form as a feature and uses WSP builder to bundle it as a solution.
The trick is to select "centrally managed data connection library (advanced)" when you modify the data connections. Copy the UDCX out of the data connection library that you used, modify it as desribed in the post. Then upload it in Central Administration -> Application Management -> Manage data connection files. Then deploy your InfoPath forms. Note that if you have managed code, the DLL not only has to be in the GAC but it also needs to be in the Feature folder .
I have to confess that we had major problems trying to create a feature for the InfoPath forms. It kept saying the form was not browser enabled which it clearly was. In the end because we only had 3 forms we gave up and installed it manually. Low and behold it worked in the browser perfectly. I should add that the forms are really quick to load, so much better than using the InfoPath client.
I recently found that with an InfoPath form with managed code you can modify the manifest.xsf manually in NotePad and modify any urls. Publishing the form from VS will then create an XSN with the correct urls. This avoids using the data connection wizrd which will try to access the url.
Now I already new that you can convert the data connections into a UDCX file and then store that in a local data connections library but the path to the data connections library was still hard coded in the XSN with the server name. So if you deploy to production the InfoPath form is looking for the data connection library you used in development. It seemed like a ridiculous situation.
But finally I stumbled on this post which explains what to do. The post deploys the InfoPath form as a feature and uses WSP builder to bundle it as a solution.
The trick is to select "centrally managed data connection library (advanced)" when you modify the data connections. Copy the UDCX out of the data connection library that you used, modify it as desribed in the post. Then upload it in Central Administration -> Application Management -> Manage data connection files. Then deploy your InfoPath forms. Note that if you have managed code, the DLL not only has to be in the GAC but it also needs to be in the Feature folder .
I have to confess that we had major problems trying to create a feature for the InfoPath forms. It kept saying the form was not browser enabled which it clearly was. In the end because we only had 3 forms we gave up and installed it manually. Low and behold it worked in the browser perfectly. I should add that the forms are really quick to load, so much better than using the InfoPath client.
Subscribe to:
Posts (Atom)