building from source

[Moorea]

Hey Freddie,

I tried to build Mojo from source, checked out from google and I get the following errors:

2>c:\cygwin\home\dl\mojoware-read-only\scrib_compiler\..\\mojo_engine\\mojo_engine.h (35): fatal error C1083: Cannot open include file: 'files.h': No such file or directory

Is this a .h you forgot to check in or it's supposed to be generated by the build and it isn't for me somehow ?

I'm using Microsoft Visual Studio 2010
Version 10.0.21006.1 B2Rel
Microsoft .NET Framework
Version 4.0.21006 B2Rel

Installed Version: VC Express

Microsoft Visual C++ 2010

Which is the first time I do (I'm used to straight makefile for c/c++ and never done windows programming but I'm intrigued and want to give it a shot - but maybe I'm missing some obvious steps - note that when opening the solution it complained about not supporting the installer and readme types but seems happy with the rest)

[Freddie]

Sorry about that.

I thought I prevented this because usually after I do a commit, I make a new folder and check out the project from scratch and make sure it builds.

There isn't any files.h in the project. There used to be, but I renamed it. The line that includes it should have been erased.

I think the reason the program builds for me anyway is that my copy of Visual Studio is set to look for include files in another project that happens to have an unrelated file called "files.h."

If you erase "#include files.h" I think it will build. Or wait till tomorrow and I'll do a new commit.

[Moorea]

Thanks for the quick reply - I should have tried removing it - I guess visual studio doesn't have "organize imports" like eclipse has (which for java deletes all unused imports)

The build went further but then failed on

4>c:\cygwin\home\dl\mojoware-read-only\mojo_app\cScrobMgrIm.h(15): fatal error C1083: Cannot open include file: 'tPt.h': No such file or directory

#include <tPt.h>

which I also commented out (it 2 files, the above and another one) and it passed

then next error is :

1>mojo_app.rc(33): error RC2135: file not found: E:\d\sou\cpp\Mojo\mojo_app\mojo_app.ico

which I guess is that you have hardcoded path to resources ?

[Moorea]

removed all the "E:\\d\\sou\\cpp\\Mojo\\" and replaced by "..\\" it seems to get further

ps: if you open the svn repository for checkins I could check in the changes :-)
(it's probably early)


last error but somehow vc continues despite it is :

3>------ Rebuild All started: Project: mojo_engine, Configuration: Release Win32 ------
3> stdafx.cpp
2>LINK : fatal error LNK1181: cannot open input file 'mojo_engine.lib'

[Freddie]

The rc file gets generated by Visual Studio. I didn't realize it was using absolute paths. If you change that file, Visual Studio may change them back.

The paths probably need to be changed in the resource editor on the property pane for each icon. I'll do it tomorrow morning.

Thanks for telling me about this.

[Freddie]

last error but somehow vc continues despite it is :

3>------ Rebuild All started: Project: mojo_engine, Configuration: Release Win32 ------
3> stdafx.cpp
2>LINK : fatal error LNK1181: cannot open input file 'mojo_engine.lib'
I get that too sometimes. Maybe there's something wrong with my dependency settings. When it happens I just build a second time and it completes almost instantly.

I made all the other changes you mentioned and I'll commit a new build today. I'm trying to complete the GUI dialog box that people will use to enter hotkey triggers. This will be a very important part of the program, and I'm changing the way triggers work compared to HotkeyNet, so it's a lot of work and it's been hard to design the dialog box in a way that's easy to use and looks good.

The new triggers can include an unlimited number of keys (useful when sending triggers from other programs, etc.)

The new triggers can include any number of main keys without declaring them as modifiers, so you can press "chords" on the keyboard.

The new triggers can be just a modifier or end with a modifier.

[Moorea]

Thanks for the update, but you left 1:

4>c:\cygwin\home\dl\mojoware-read-only\mojo_app\cScrobIm.h(14): fatal error C1083: Cannot open include file: 'tPt.h': No such file or directory

would you add people (me) to the project so that type of stuff I can check in or submit a check in directly ?

[Freddie]

4>c:\cygwin\home\dl\mojoware-read-only\mojo_app\cScrobIm.h(14): fatal error C1083: Cannot open include file: 'tPt.h': No such file or directory
Thanks, I'll fix that in the next build.


would you add people (me) to the project so that type of stuff I can check in or submit a check in directly ?
I won't be giving commit permission to anyone, at least not for the forseeable future.

[Moorea]

does goggle let you setup such as commit gets submitted as patch proposal that you can easily review and accept (or reject/modify) ? otherwise I guess we can send patches

[Freddie]

does goggle let you setup such as commit gets submitted as patch proposal that you can easily review and accept (or reject/modify) ? otherwise I guess we can send patches
I don't know, but there's a copyright issue. I'm planning to retain the full copyright to the version of Mojo in the mojoware repository. If people send code to me, even if it's just for consideration, that may raise legal issues. I don't know any IP lawyers who I can consult for free about this so I'd just rather not go near it for the time being.

[Moorea]

Thanks, as revision 13 it all builds out of the box !
(the first launch it had a strange black bar + 2 buttons; one of them called "add a toon" but nothing happened when clicking it) - after clicking "computers" it went away permanently)

[Freddie]

Thanks, as revision 13 it all builds out of the box !
Yay. :)


(the first launch it had a strange black bar + 2 buttons; one of them called "add a toon" but nothing happened when clicking it) - after clicking "computers" it went away permanently)
The bar is something I had just begun to work on when I posted that build. I tried to disable it in build 13 so people wouldn't worry about it, but your comment makes me realize that people may see it once when the program starts up depending on settings left over from the previous build.

In the next build the bar will look like it's attached to the thing it affects and hopefully it won't look strange.

[Moorea]

Another question: I'm now using visual studio 2010 ultimate beta 2 and it still complains that it can't open MojoInstaller part of the project - any idea what extension or component I would need to get for that one ? (not that I really care about building the installer but to avoid the error message at startup and for completeness sake)

(I didn't see that on the otherwise very nice
http://mojoware.org/p/overview-for-programmers.html
unless "clickonce" is the stuff I need to get ?)

[Freddie]

Yeah it would be nice if people can just download the whole thing and build it without any problems.

I don't know what could be missing. The installer (unlike everything else) is a .NET program and I know practically nothing about .NET.

I'm trying to remember what I did when I installed VS 2010 and wrote the installer. I think I just went with the defaults. Did you include the C# / .NET stuff when you installed it?


(I didn't see that on the otherwise very nice
http://mojoware.org/p/overview-for-programmers.html
unless "clickonce" is the stuff I need to get ?)
Thanks. I think everything ClickOnce needs comes automatically with .NET but maybe I'm wrong, I know next to nothing about .NET.

[Moorea]

hmmm it's possible I only put C++ - I'll rerun setup - thanks

[thinus]

I don't know, but there's a copyright issue. I'm planning to retain the full copyright to the version of Mojo in the mojoware repository. If people send code to me, even if it's just for consideration, that may raise legal issues. I don't know any IP lawyers who I can consult for free about this so I'd just rather not go near it for the time being.

Uhm....am I missing something? You have the GNU GPL license published with the source so I assume the code is made available with a GNU GPL license which in turn means anyone can modify and distribute the code.

Copyright as far as the GNU GPL is concerned is to ensure you get credit for what you write and that someone doesn't take your code, claim they wrote it and then take ownership of the code. From the GNU GPL FAQ:

Why should I use the GNU GPL rather than other free software licenses?
Using the GNU GPL will require that all the released improved versions be free software. This means you can avoid the risk of having to compete with a proprietary modified version of your own work.

And with "free software" they don't mean you can't sell it, just that if you sell it / distribute it then you need to make the source code available as well and whoever you sell / distribute it to has the right to sell / distribute it as well without any obligation to you.

Some other useful stuff:

Why does the GPL permit users to publish their modified versions?
A crucial aspect of free software is that users are free to cooperate. It is absolutely essential to permit users who wish to help each other to share their bug fixes and improvements with other users.
Some have proposed alternatives to the GPL that require modified versions to go through the original author. As long as the original author keeps up with the need for maintenance, this may work well in practice, but if the author stops (more or less) to do something else or does not attend to all the users' needs, this scheme falls down. Aside from the practical problems, this scheme does not allow users to help each other.
Sometimes control over modified versions is proposed as a means of preventing confusion between various versions made by users. In our experience, this confusion is not a major problem. Many versions of Emacs have been made outside the GNU Project, but users can tell them apart. The GPL requires the maker of a version to place his or her name on it, to distinguish it from other versions and to protect the reputations of other maintainers.

And:

Does the GPL require that source code of modified versions be posted to the public?
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.

The full FAQ is here (http://www.gnu.org/licenses/gpl-faq.html).

In other words, anyone can take an exact copy of the source and start a new GNU GPL project with your source and develop their own version in parallel with yours.

[Freddie]

Uhm....am I missing something?

Yes, multilicensing. I don't know if I'll do it, but I'm going to preserve the option.


http://en.wikipedia.org/wiki/Multi-licensing

[thinus]

Yes, multilicensing. I don't know if I'll do it, but I'm going to preserve the option.


http://en.wikipedia.org/wiki/Multi-licensing

Interesting. So basically keeping the option open of a premium service at a price and an Open Source project limited in some way. Which means you cannot use any contributions / modifications made under the GPL license. Ok, got it.

[Moorea]

hmmm it's possible I only put C++ - I'll rerun setup - thanks
that was it indeed - added C# and now it's happy


ps: I guessed as much about mutli licensing / keeping your options open for later and that's sounds fine / fair

[Freddie]

that was it indeed - added C# and now it's happy
Good. :)

I'll add a note to the readme about that.

Edit:

Thanks a lot for helping me fix this. Getting it to build on any machine that downloads it, is important.

[Moorea]

I finally picked up the latest updates; here are the errors I get:

3>mojo_app.rc(704): error RC2135: file not found: E:\d\sou\cpp\mojo_svn\mojo_art\wow-logo-70x69.bmp
3>
3>
3>mojo_app.rc(705): error RC2135: file not found: E:\d\sou\cpp\mojo_svn\mojo_art\wow-logo-green-70x69.bmp
3>
3>
3>Build FAILED.
3>
3>Time Elapsed 00:00:00.35



this next one is probably on purpose if you want the installer to be signed only by you ? maybe should have some sort of "unsigned" or "community release" alternative (I don't really need to build the installer so I don't care for that error too much) ?

2>------ Build started: Project: MojoInstaller, Configuration: Release x86 ------
2>Build started 1/23/2010 12:35:09 PM.
2>C:\Windows\Microsoft.NET\Framework\v4.0.21006\Micr osoft.Common.targets(1886,9): error MSB3323: Unable to find manifest signing certificate in the certificate store.
2>
2>Build FAILED.


========== Build: 1 succeeded, 2 failed, 2 up-to-date, 0 skipped ==========

[Moorea]

I edited mojo_app/mojo_app.rc to remove the full path and replace by ..\\mojo_art and got going;
when trying to do svn diff to post the changes:

$ svn diff
Index: mojo_app/mojo_app.rc
================================================== =================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream


maybe you can change the type to be text, as it is text

[Freddie]

3>mojo_app.rc(704): error RC2135: file not found: E:\d\sou\cpp\mojo_svn\mojo_art\wow-logo-70x69.bmp
3>
3>
3>mojo_app.rc(705): error RC2135: file not found: E:\d\sou\cpp\mojo_svn\mojo_art\wow-logo-green-70x69.bmp
I'll add them, thanks.



this next one is probably on purpose if you want the installer to be signed only by you ? maybe should have some sort of "unsigned" or "community release" alternative (I don't really need to build the installer so I don't care for that error too much) ?
It's not on purpose. ClickOnce requires a certificate and since I'm completely befuddled by Microsoft's certificate stuff I just pressed some default key or other.

Can somebody tell me how to do this? If not, when I get time, I'll try to figure it out.

[Moorea]

I get some errors while running, opening the mouseover_blue.jpg and mouseover_gray.jpg - seems like those 2 are installed by the installer - anyway to put them with the rest of the resources ? or maybe have a small script to copy what's missing when not using the installer (for now I just copied them myself to Release/ dir)

another problem I have is soon after I start another mojo on another computer I get thrown in the debugger:

HEAP[mojo.exe]: HEAP: Free Heap block 20efa68 modified at 20efa90 after it was freed
Windows has triggered a breakpoint in mojo.exe.

This may be due to a corruption of the heap, which indicates a bug in mojo.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while mojo.exe has focus.

The output window may have more diagnostic information.
The thread 'Win32 Thread' (0xbf4) has exited with code 0 (0x0).

[Freddie]

I edited mojo_app/mojo_app.rc to remove the full path and replace by ..\\mojo_art and got going;
when trying to do svn diff to post the changes:

$ svn diff
Index: mojo_app/mojo_app.rc
================================================== =================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream


maybe you can change the type to be text, as it is text

I'm not sure what to set the mime type to, so I just set it to text/text.

(I tried leaving it blank because the SVN docs say blank means text, but Tortoise SVN won't let me do that.)

[Moorea]

other question: where does mojo store settings; I want to reset like if I never installed to check some FAQ question and i can't tell right now if it's working because I already setup my mouseover long ago or if you fixed the initial setup issue

[Freddie]

other question: where does mojo store settings; I want to reset like if I never installed to check some FAQ question and i can't tell right now if it's working because I already setup my mouseover long ago or if you fixed the initial setup issue

Just erase this directory:

%localappdata%\mojo

It contains three settings files:

%localappdata%\mojo\mojo.settings.txt

%localappdata%\mojo\mojo.fig.xml

%localappdata%\mojo\mojo_engine.settings.txt

[Moorea]

Thanks - I see it says "not implemented yet" but what would be computer broadcast ?

(I'll put the answer in the faq)

[Freddie]

Thanks - I see it says "not implemented yet" but what would be computer broadcast ?

(I'll put the answer in the faq)
We haven't talked about the details but I'd describe it like this.

1. It copies mouse and keyboard input from local computer to other computers (as opposed to copying mouse and keyboard from the local focus window to other windows).

or another description of the same thing:

2. Think of it as an emulation of hardware KM multiplexing, except with the mouse motion scaled for the size of the focused monitor on each PC.

(I"m not sure how to deal with multiple monitors ... maybe this mode isn't such a great idea.)

[Freddie]

I'm not sure what to set the mime type to, so I just set it to text/text.

(I tried leaving it blank because the SVN docs say blank means text, but Tortoise SVN won't let me do that.)
I managed to make it blank by clicking "remove" instead of erasing it and clicking "okay."

And I'm pretty sure that's right because Tortoise SVN has automatically set .txt files that way.

[Moorea]

thx, updated the faq some more

about the crash I can somewhat reproduce it by

- starting 2 wow windows on main pc
- starting mojo (from VC debugger)
- starting mojo on 2nd pc

"doing something else" on main pc (like typing in the faq)

earlier; before I cleared my settings, it was happening all the time at each launch of the 2nd mojo but I also had the 2 wow windows logged in and playing; so I'm not sure exactly which parameter makes it harder to reproduce - have you seen that error before - is it useful I try to reproduce it ?

[Freddie]

thx, updated the faq some more

about the crash I can somewhat reproduce it by

- starting 2 wow windows on main pc
- starting mojo (from VC debugger)
- starting mojo on 2nd pc

"doing something else" on main pc (like typing in the faq)

earlier; before I cleared my settings, it was happening all the time at each launch of the 2nd mojo but I also had the 2 wow windows logged in and playing; so I'm not sure exactly which parameter makes it harder to reproduce - have you seen that error before - is it useful I try to reproduce it ?
The only crash I ever see is when I debug a release build. The debugger crashes at a certain place in the source. I think it's a bug in the debugger.

The program shouldn't be able to crash because it has a "last resort" crash handler that should intercept any exception. Worst case, in the debugger, the program should generate an exception. Outside the debugger, the program should show a dialog box asking the user to send me a minidump.

The code that displays the WoW icons is unfinished and it's quite possible it has a null pointer error in it or something like that. But it shouldn't make the debugger crash. It should just generate an exception.

To switch to a debug build, go to Build : Configuration Manager : Active Solution Configuration.

[Moorea]

I thought I had found a simpler repro sequence but it actually doesn't really always happen right away, here it is anyway:

erase all settings on both computers

start mojo from debugger (start new instance) on main pc; accept license
start mojo on 2nd computer; accept license

go to mouseover settings and connect the 2 screen (I used my main on the right of the 2nd pc; if that matters)

using mouseover start wow on 2nd pc

start wow on first pc

type stuff on bot password boxes

setup pause has windowbroadcast toggle; use it on/off a few times

toggle wow from windowed to fullscreen and back

type some more

crash

[Freddie]

It just occurred to me that the crash could be happenin before the last-resort crash handler gets installed.

Is this happening in the debugger ?

[Freddie]

Which one is crashing? The one that's running in the debugger?

Is it literally crashing or is the debugger stopping at an exception?

Are you debugging a release build or debug build?

[Moorea]

it's just going into the debugger with no visible source stack trace - it was just running the default "start new instance" under debug - I'm now "running" the release (without debugger) and I haven't seen any complaint (do you have a log file where messages like
HEAP[mojo.exe]: HEAP: Free Heap block 20efa68 modified at 20efa90 after it was freed
would go when starting from windows normally ?)

[Freddie]

it's just going into the debugger with no visible source stack trace - it was just running the default "start new instance" under debug -
If it crashes in a way that opens the debugger, it won't be running in the debugger. There's a window that shows the call stack but I think it's closed by default. To see it, you probably have to go to Debug : Windows and select the Call Stack window.


(do you have a log file where messages like
HEAP[mojo.exe]: HEAP: Free Heap block 20efa68 modified at 20efa90 after it was freed
would go when starting from windows normally ?)
So far as I know, that particular error only gets noticed in debug builds and when they happen, the debugger breaks in and displays a dialog box, so I don't bother logging them.

Most errors that can occur in release builds get logged in two files in

%localappdata%

If a memory error causes a crash, the program's "last resort" exception handler should be creating a mini dump with crash data including the address of the error. When the debugger gets called up automatically like it's doing for you, I think it already has the crash dump loaded.

You're running your own build, right, so the debugger should have all the symbol tables etc. that it needs to show you everything.

You can run the program in the debugger to begin with. That way when it crashes it will just stop wherever it crashed.

Open the Call Stack window (explained above) and you should be able to see instantly where it crashed.

[Freddie]

Moorea, I wonder if you're just hitting an assert(). If you hit one, it drops you into the debugger. If that happens the debugger should show you a dialog box when it comes up asking you what you want to do.

I think the dialog box offers you "Abort" and "Retry." Click Retry. Then another box. Click "Break."

Now you can look at the call stack (but you have to open the window as described above).

You should find yourself in Microsoft CRT library code looking at a function called (I think) _wassert.

[Freddie]

another problem I have is soon after I start another mojo on another computer I get thrown in the debugger:

HEAP[mojo.exe]: HEAP: Free Heap block 20efa68 modified at 20efa90 after it was freed
Windows has triggered a breakpoint in mojo.exe.

I'm sorry, I overlooked this post. This whole time we've been talking about the crash, I didn't realize you had gotten this error message. You mentioned it again later but I thought you were making up an example.

Please ignore everything I said above about exceptions, the debugger, etc.

You found the cause of the crash. I don't what else you can do. I mean, if you want, of course you can try to find the place in the code where the memory gets overwritten but since you're not familiar with the code or the debugger I think it would be amazingly hard.

[Freddie]

I get some errors while running, opening the mouseover_blue.jpg and mouseover_gray.jpg - seems like those 2 are installed by the installer - anyway to put them with the rest of the resources ?
I think the program loads them from its own folder (the folder with the EXE) at run time. SVN puts them in the mojo_art folder.

Just copy them into the folders with the EXE's. The release EXE is in the Release folder. Debug build is in Debug folder.

[Moorea]

looks like you forgot to make or check in the changes to

mojo_app.rc(765): error RC2135: file not found: E:\d\sou\cpp\mojo_svn\mojo_art\wow-logo-70x69.bmp


replace:
IDB_WOW_LOGO BITMAP "E:\\d\\sou\\cpp\\mojo_svn\\mojo_art\\wow-logo-70x69.bmp"
IDB_WOW_LOGO_GREEN BITMAP "E:\\d\\sou\\cpp\\mojo_svn\\mojo_art\\wow-logo-green-70x69.bmp"
by
IDB_WOW_LOGO BITMAP "..\\mojo_art\\wow-logo-70x69.bmp"
IDB_WOW_LOGO_GREEN BITMAP "..\\mojo_art\\wow-logo-green-70x69.bmp"



For
1>C:\Windows\Microsoft.NET\Framework\v4.0.21006\Micr osoft.Common.targets(1886,9): error MSB3323: Unable to find manifest signing certificate in the certificate store.
any idea what I need to do (install some clickonce sdk; or something ?)

[Freddie]

looks like you forgot to make or check in the changes to

mojo_app.rc(765): error RC2135: file not found: E:\d\sou\cpp\mojo_svn\mojo_art\wow-logo-70x69.bmp


replace:
IDB_WOW_LOGO BITMAP "E:\\d\\sou\\cpp\\mojo_svn\\mojo_art\\wow-logo-70x69.bmp"
IDB_WOW_LOGO_GREEN BITMAP "E:\\d\\sou\\cpp\\mojo_svn\\mojo_art\\wow-logo-green-70x69.bmp"
by
IDB_WOW_LOGO BITMAP "..\\mojo_art\\wow-logo-70x69.bmp"
IDB_WOW_LOGO_GREEN BITMAP "..\\mojo_art\\wow-logo-green-70x69.bmp"



For
1>C:\Windows\Microsoft.NET\Framework\v4.0.21006\Micr osoft.Common.targets(1886,9): error MSB3323: Unable to find manifest signing certificate in the certificate store.
any idea what I need to do (install some clickonce sdk; or something ?)
Was that a change I made or was it a change you made when you edited the RC file by hand?

If it was my change, I think I was just trying to change an absolute path to a relative one.

The files are in the repository dated Jan. 6. I just looked on Google.

I don't know what's wrong. Do you have any ideas?

[Moorea]

the line above that one was something I stepped on a while ago, from very early compile error; the 2 next ones mentioned now is what I've been saying since post #21 and when you said in post #23 "I'll add then" maybe I should have picked up - it's not about adding but just removing the bogus absolute path

so yes you need to edit by hand mojo_app.rc at line 765 and replace:
IDB_WOW_LOGO BITMAP "E:\\d\\sou\\cpp\\mojo_svn\\mojo_art\\wow-logo-70x69.bmp"
IDB_WOW_LOGO_GREEN BITMAP "E:\\d\\sou\\cpp\\mojo_svn\\mojo_art\\wow-logo-green-70x69.bmp"
by
IDB_WOW_LOGO BITMAP "..\\mojo_art\\wow-logo-70x69.bmp"
IDB_WOW_LOGO_GREEN BITMAP "..\\mojo_art\\wow-logo-green-70x69.bmp"
so it works for me and everybody who would checkout from source (it'll still work for you too)
if the UI automatically generates/edit that when you add a resources you should add a todo postit note for you to manually fix them each time you add a new one; or maybe write a simple sed like script to replace "E:\\d\\sou\\cpp\\mojo_svn\\" by ".." before check in


ps1: did you get the dump I emailed ?
ps2: any idea about clickonce/installer?

[Freddie]

Oh you were telling me to replace. :) I thought you were showing me an error message from something. :)

I thought it looked kinda strange for an error message. :)

[Moorea]

thx, the resource file is fixed in 21 - any idea about the installer error message ?

[Freddie]

I know generally what it's about but I don't know how to fix it. If you want to read about Windows certificate store and tell me, I'll do it.

The clickonce installer is looking for my public key to add it to the installation package. That key isn't part of the source code. It's something (I think) that Windows keeps in kernel mode data structures on the PC where I build Mojo. There must be some way to export it to other PCs but I don't know how.

It might be easier to use your own certificate. Visual Studio will make one for you when it builds the installer if you select an option or press a button in "Properties" in the MojoInstaller project. I forget how to do it exactly but it's very easy. Only thing is, though, if you do that and you distribute Mojo to yourself you may screw up your Mojo installation since ClickOnce may think the key is wrong.

[Moorea]

Ah found ! In "Signing" tab, just uncheck "Sign the clickonce manifest" and presto, it works without errors now

If you created a test certificate, there is 0 security to that so you may as well uncheck it (until you get a real cert)

[Freddie]

Ah found ! In "Signing" tab, just uncheck "Sign the clickonce manifest" and presto, it works without errors now
Good.


If you created a test certificate, there is 0 security to that so you may as well uncheck it (until you get a real cert)
If I uncheck it, ClickOnce won't publish it. It requires a signature for publication.

[Moorea]

hmm odd I was able to publish to my local directory - is there something special running on the web side ?

[Freddie]

hmm odd I was able to publish to my local directory - is there something special running on the web side ?
I was just relying on ClickOnce's documentation. They say the certificate has to be signed in order to publish it.