Deploying a WPF application using ClickOnce and Team Build - wpf

I have a WPF application that builds fine, I can even publish it (localhost) using ClickOnce - no problem.
I want to create a Team build that will update the ClickOnce site, but can't find anyone that has done this or knows how.
Any ideas?

I was able to use this code here to get what I wanted out of this:
http://www.imaginaryrealities.com/post/2009/03/29/Updating-a-ClickOnce-manifest-using-MSBuild.aspx
This was a little too much for me (we aren't signing our manifests, for example), but it'll definitely get you most of the way there.
The only thing missing is copying the files to your webserver once they are all packaged, but if you know anything about MSBuild, you ought to be fine there.
Also, be sure and use "MSBuild" when doing searches for this kind of thing... "Team Build" will generally only get you marketing material.
Good luck!

Related

Replace Apache CXF with Sun Metro in TomEE

I have faced a problem in our development project today. I wanted to create webservice in TomEE 1.6.0+ environment in the same way as I did earlier in Glassfish environment. I had a lot of trouble with it so I thought I try to replace Apache CXF with Sun Metro stack (version 2.3).
I haven't found any tutorial on it so I tried to do something myself. My solution was to delete all of the cxf-*.jar and openejb-cxf-*.jar from the TomEE lib folder and I have added webservices-*.jar (only the following 4 libraries: rt, tools, extra, extra-api) from the metro distribution. I have looked into the installation ant script and I have selected files based on the installation definition.
It looks now everything is perfect. Now I can work the same way with webservices as I worked before. My project deploys smoothly into TomeEE environment.
My question is quite simple now:
Is it a correct solution or looks like a hack?
Thanks in advance for any feedback.
The definitive answer would come from someone on the TomEE project, but I'm surprised this worked... but I'm happy it did for you.
TomEE has bindings to CXF for CDI for specific purposes: it can scan for jax-rs annotations, inject fields, expose services, etc (too many to enumerate). As long as your application isn't reliant on any of that functionality, you might be ok.
Since you're running an unsupported configuration, the key here is thorough testing. I would create a battery of integration tests (SOAP-UI?) that will get you a comfortable level of branch coverage... definitely at least cover your happy paths.
The nice thing about TomEE is that it's incredibly modular as you discovered. Good luck, and post back for the community how everything is going later on.

How to create a setup of an Windows application using PowerBuilder

I am a newbie for PowerBuilder and for Windows application. I have few projects which consists corresponding code in it and after merging all that I get the final product. The problem I am facing right now is that I don't know how to make a setup of my Windows app using PowerBuilder. If I can get step by step procedure with tiny explanation, I will be able to achieve it already. Have tried Google but ended up with complex confusion. I have created the .exe, but that .exe does not work on any other computer. So please guys help me out.
Thanks
There are two parts to creating a setup program for your application: defining the files and other resources that need to deployed, and building those resources into a setup executable package.
For defining files and resources, you've made it impossible for anyone to even take a shot by referring to two very different (but similar origins) versions of the product in your tags: PowerBuilder (aka PowerBuilder Classic) and PowerBuilder.NET. The deployment requirements for apps built from each of these is very different. However, even if we knew, the best advice is to go through the manuals and review what is required of the features of your specific application. (e.g. if you don't use rich text, deploying the files required to support it would be a waste). A generic list is, IMHO, just bad advice.
As far as building a setup package goes, the first decision is which package building software to pick (none comes with PowerBuilder). Any Windows setup package builder should do. I've used InstallShield and Inno, vastly preferring the latter (after many years of using the former). I know you want steps to walk you through, but a walk through is impossible before picking the software, and frankly, walk throughs of these setup building software has been done elsewhere much better than I'd do.
The bottom line is that the answer isn't as simple as you seem to have been hoping, but it is attainable.
Good luck,
Terry.

uBootstrap for Umbraco

I have a legacy Umbraco site which I need to make responsive. I decided to use uBootstrap for this. I downloaded the files, but I cannot find any documentation on how to integrate this with my current site. Is there something I need to install? There's no installer file.
There is documentation here, presumably where you downloaded it from:
http://our.umbraco.org/projects/starter-kits/ubootstrap
It is a starter kit, so you will probably only really be able to use it when you are creating a brand new site.
Packages listed at http://our.umbraco.org will always have a "Package discussions" link at the bottom for reading or raising questions just like this.

Could not load file or assembly ‘System.Web.Silverlight’

I really need some help with this as I have been trying to fix this for months and I can't figure it out.
I run an online chess site written in Silverlight 3.0
The architecture is Silverlight Client connecting to a WCF service that reads and writes data to a SQL Server database. It is hosted on Godaddy,
Once every so often I get the following error:
Could not load file or assembly ‘System.Web.Silverlight’ or one of its dependencies.
The system cannot find the path specified.
If I leave it alone it will fix itself after a few hours, however usually I just make a new publish of my application and it goes away. Also all the pages in the solution get this message not just the Silverlight application. So I have an aspx page with top ranks that does not use Silverlight but is in the same solution it also gets the same error. Its almost like the whole site dies.
This does not seem like a huge issue but it makes going on vacation hard since my site can go down at any time I am away. Also this seems to happen the most when I am sleeping so I often don't get to fixing it until I have already lost hours of potential logins.
This sounds like a ASP.NET problem. I suspect you are using ASP.NET with the Silverlight 2.0 ASP.NET server control. Ditch it and code the Object tag yourself, that way you no longer need that special assembly in your web site.
I received an answer on the Silverlight.net forums, it is a cobination of two items:
Like Anthony Suggested use an Object Tag to embed your Silverlight control.
Remove all refferences of System.Web.Silverlight from all your projects and never use it again.

Postbacks not working in Dot Net Nuke 5.2.1 with javascript disabled

I am working on my first DotNetNuke website and there is a requirement for all the custom module functionality I am developing to be available with JavaScript disabled.
However, when I create a module that contains a simple submit button, i.e.<input type="submit" />, DotNetNuke displays a critical error with JavaScript turned off but works as expected with JavaScript turned on.
When I attach to the running process using Visual Studio, the unhandled exception is thrown from admin/Skins/Nav.ascx.vb line 177. The inner exception message is "Invalid JSON primitive: ."
My research online only managed to turn up this forum post (Postbacks are not working when Javascript is disabled in the browser) that appears to be the same problem as mine, but no solution is provided.
Can anyone shed any light on this issue? Is it viable to be attempting to write non-JavaScript functionality in this version of DotNetNuke?
Update: it turns out that another website designed recently with Dot Net Nuke by the company I am working for is having the same problem with non-javascript postbacks when using DNN version 5.1.4 but it does not have the problem (i.e. it can postback without javascript) in DNN version 5.0.1.
So perhaps a hard dependency on javascript has been introduced at some point after version 5.0.1. We are investigating this possibility further and I will keep this question updated as we go. Obviously I still welcome anyone's input on the subject.
Update: i've started a thread on the Dot Net Nuke forums to see if I can get any help there. If any solutions come up I'll post them here. Trying to find official DNN stance on support for javascript disabled functionality
One of the developers in the office found a workaround to get postbacks working with javascript disabled. Unfortunately since he does not have a Stack Overflow account, I will try to translate his solution as best I can for those who are interested. Bottom line is postbacks with Javascript disabled is possible once you make a few changes to the Dot Net Nuke environment.
Step 1 - Change the menu module. In our case we used the Telerik RadMenu.
<dnn:NAV runat="server" id="dnnNAV" ProviderName="DNNMenuNavigationProvider" IndicateChildren="false" ControlOrientation="Horizontal" CSSControl="mainMenu" />
becomes
<dnn:RADMENU runat="server" id="dnnRADMENU" MaxLevel="2" EnablePageIcons="False" PagesToExclude="" ShowPath="True" />
Step 2 - Remove the actions and visibility modules.
<dnn:ACTIONS runat="server" id="dnnACTIONS" ProviderName="DNNMenuNavigationProvider" ExpandDepth="1" PopulateNodesFromClient="True" />
<dnn:VISIBILITY runat="server" id="dnnVISIBILITY" minicon="images/DNN-minus.gif" maxicon="images/DNN-plus.gif" />
Step 3 - Download the DNN source and make two changes in the LibraryUI\Utilities\ClientAPI.vb file.
Line 155:
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
becomes
If Not objButton.Page.IsPostBack Then
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
End If
Line 355:
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
becomes
If Not objPage.IsPostBack Then
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
End If
Step 4 - compile the Dot Net Nuke library.
Note: Also make sure you are not logged in as an admin or host, as the admin/host panel at the top of the page will also break if you attempt to postback with javascript disabled.
Hope this helps someone else. If you feel like I'm missing some important details, let me know and I'll try and fill in what's needed.
DotNetNuke relies heavily on JavaScript and I doubt there is a real easy way around it - at least considering you need to support all functionality. Perhaps you can clarify that?
The the bottom line here is that you're going to need to modify DotNetNuke to meet your needs. It certainly isn't impossible to get it working, but I would venture a guess that it just plain isn't worth it for most people.
If, as you said, you need to retain ALL functionality without using JavaScript, you're going to have a pretty substantial amount of work to do.
I'd suggest, to get started, you download the source package, set up a development environment on your local machine, turn off JavaScript in your browser and start taking notes. This will help to determine the level of effort involved.
I'm guessing you won't get a lot of responses out of this one (as the poster in the forum thread you linked to didn't) as very few people have sat down in front of DotNetNuke with this as a requirement.
Also, keep in mind that any time you're making substantial changes to the DotNetNuke framework, you're interfering with your ability to easily perform upgrades in the future. Just another thing to think about.
I believe that I've seen the leadership in DNN say that they've taken a hard dependency on JavaScript, and have no intention at this time of considering a non-JavaScript compatible scenario.
That being said, being able to do a simple postback shouldn't be too difficult to support. I would look around in the Client API area for the error that you're describing. A lot of the Client API code is in the DotNetNuke.WebUtility assembly, which is a separate download from CodePlex to get the source.

Resources