I tried the above solution,but unfortunately there is no difference in behaviour.So kindly suggest how to proceed further.
Regards,
Ranjan VijayKumar.
Well you have a crash of some kind, not a WiX issue. If the install didn't fail, then you just have a crashing app. Tell someone what the exception is, the actual error message. Add some debugging to your program and perhaps try/catch exception handling and tracing to see how far it gets and where it crashes. For debug purposes, have it show a message box as the first thing it does so you can see that it loads and has no missing dependencies. Verify in your code that the things you are doing are actually working etc. I'm guessing it's been voted down most likely because it's not a WiX question at all - it's just your code crashing or a missing dependency for which have supplied no data at all.
See the Wix samples for how to create a shortcut the proper way.
A couple of more links:
Wix Toolset Manual Table of Contents
How To: Files, Shortcuts and Registry
Related
I'm not sure if I'm missing something here, but it doesn't appear to be possible to debug exceptions in Jetbrains Rider.
I have an incredibly simple piece of code that throws an exception (invalid file name) and there is no way I can find to
a) stop on the exception line in my code raising the exception, and
b) view the value of any variables in my source code that may have contributed to the exception.
I've recorded a sample video here that shows the debug attempt, and why it seems illogically impossible.
Has anyone found a way of debugging this stuff? Is Rider actually broken?
Sample video showing (attempted) debug session
For anyone experiencing the same situation, enable "Any Exception" and disable "Only break on exceptions thrown from user code" in Breakpoint Options.
You can also (as #mu88 mentions) disable debugging of external sources, but that simply reduces the clutter in stack frames.
New to VisualStudio 2015, but not to programming. Have searched both Google and here for a lead on this, but considering the available search terms, I might not immediately uncover them.
I was looking into porting an old VB6 (200k+ LoC) to VB.Net in VS2015. Mostly just poking around to determine viability. Using a project converter, and have resolved most of the initial errors, and am familiar with how the Error List works.
However, it is throwing a new one at me. It now only has two lines of error, both showing the same thing. They both say:
" & ErrorName
That's a Quote, Ampersand, and ErrorName. That's all that show up on the error list line. No file. No line number. Double click on them does nothing.
I thought perhaps the project was corrupted, so I completely re-created it, adding all the modules, forms, classes, etc again, and it found a lot more errors to fix, which I fixed, and now these two lines show up again.
Does anyone have any indication where this is coming from, or, better yet, how to fix?
I've seen VB programmers report this misbehavior before, never with a good lead to explain the problem. It is specific to VS2015, the Roslyn integration caused many issues. In general a very buggy release, be sure to apply all available Updates, currently up to Update 3. If you have a license that includes an MSDN subscription then I recommend you install VS2012, the last "good" version of VS that was not yet affected by Microsoft's new focus on agile development.
I think the underlying issue is caused by the IDE simply not parsing the compiler error message correctly. Probably having to do with the statement with the error getting quoted in the message. Getting only part of the statement text and it fumbling quotes is a pretty good hint that this is where it went wrong.
So look at the actual output of the compiler, decent odds you'll now see the full error text. Use Tools > Options > Project and Solutions > Build and Run. Change the "MSBuild output build output verbosity" setting to Normal. After the failed build, use View > Output to see the compiler output. You'll probably have a lot of messages, consider copy/pasting the content.
I have got a minigame.exe which crashes at some point inside the game. It does not show any error message and it just says Not Responding. I am using Win 7. I want to identify the crashing point and try to fix the games problem. I think the problem might be caused due to a specific DLL imported by the executable. However, I have no clue about how to find out that specific assembly line and try to patch the executable with OllyDBG.
With the information given, this answer would need a full tutorial style, which is considered as too broad for this site. But the first step, finding out what type of crash it is and where it occurs can be explained.
I'll use WinDbg as the debugger, since I'm not familiar with OllyDbg. It is is part of the Debugging Tools for Windows and it's freely available. Install the versions, x64 or x86, that matches minigame.exe.
Start WinDbg, use the correct bitness
Run minigame.exe under WinDbg (File/Open executable). It will stop at the initial breakpoint.
Set up the symbols, at least .symfix c:\debug\symbols and .reload. This will download information needed to construct the callstack.
Continue running the application with g
Reproduce the issue / wait until it crashes
When WinDbg stops,
create a crash dump with .dump /ma c:\debug\minigame.dmp so you can analyze it later, e.g. for asking questions here, so that you needn't reproduce the bug again.
get information about the exception with .exr -1
switch to the thread that caused the exception with ~#s
look at the callstack with k
Now you should have a better understanding of the crash, perhaps enough to apply a patch, maybe not. At least it's a better starting point for further exploration.
I'm seeing a strange build bug a lot. Sometimes after typing some code we receive the following build error.
Class 'clsX' must implement 'Event PropertyChanged(sender As Object, e As PropertyChangedEventArgs)' for interface System.ComponentModel.INotifyPropertyChanged'.
And
'PropertyChanged' cannot implement 'PropertyChanged' because there is no matching event on interface 'System.ComponentModel.INotifyPropertyChanged'.
Those error should never go together! Usually we can just ignore the exception and build the solution but often enough this bug stops our build. (this happens a lot using Edit and Continue which is annoying)
We're using Vb.net and c# mixed in one big solution.
Removing the PropertyChanged event and retyping the same code! sometimes fixes this.
Question:
Has anyone else seen this problem and has some suggestions how to prevent his?
We're using a code generator that causes this error to surface but just editing some files manually triggers this exception too. This error occur's on multiple machines using various setups.
Someone had the same exact issue discussed here. It sounds like there is an issue with this build picking up an old version of a binary. I would try the following in order:
Verify all assembly references use project references where possible within the Visual Studio solution.
Disable build parallelization in case there is some weird file locking issue with concurrent project builds. Go to Tools -> Options, Projects and Solutions -> Build and Run, then set "maximum number of parrellel project builds" to 1. Not the best solution but it may help narrow down the problem.
Disable the Hosting Process in case it's locking some file causing an assembly to not get rebuilt correctly. For C# project go to Project Properties, Debug tab, and uncheck "Enable the Visual Studio hosting process". For VB.NET project you'll need to Unload Project, Edit the project file, and add <UseVSHostingProcess>false</UseVSHostingProcess> to the PropertyGroup of each configuration. Again, not the best solution but you probably won't notice a difference.
Lastly, try doing a Clean + Build to try and resolve the issue when it occurs (I know this is not a fix but it's easy enough to do), also Rebuild may be slightly different than Clean + Build so try the latter if the former doesn't work.
As I can not comment due to lack of appropriate points.
But I would like to share one of my experience:
In an aspx.cs page I was working, used to compile fine and some time gave mysterious error of a variable not defined or function not defined or sometime variable or the function defined two times. I changed possibly each and every variable and function name but there seemed no effect , but after entering a simple space or a new line at any place in the file used to solve the compile error. At one time I tried to save the file (in a different encoding as i am used to experiments) and found that the file was not saving in the correct encoding (i.e. the ansi encoding because the file had a unicode character ), I removed the unicode character and that compile error didn't bothered me again.
This unicode character problem could be (not a hard and fast rule) there so you could check it.
Nuke & restore using source control (TFS instructions here):
Make sure you have everything checked in
Exit Visual Studio
Rename the project directory to .Bak (effectively deleting it)
Reopen Visual Studio and in source control:
Get Specific Version
check 'Overwrite... not checked out' and 'Overwrite ... even if local version matches'
Re-open project
Another problem: Make sure some source files are not newer than the current date (or your date is set back). Often this happens in apps where you are doing logic that requires certain things to happen differently on certain dates. You change your clock to test it, make a revision to the source with the date advanced, set the date back, and viola, rebuild does not rebuild that file.
You say 'typing it in again' - can you try just saving? After 40 years since MULTIX the .net build still decides what has changed by checking the file timestamp.
good luck!
When you get the error, is it always on the VB calling C# side, or vice-versa, or does it work both ways?
If the answer is either of the first two situations, try building the "callee" project within the solution before building the "caller" project to see if it stops the situation.
Also, just in case it may jog something for you to think about, does this error crop up when you change a VB file or a C# file, or is there no correllation?
Oh, and sorry this looks like an answer instead of a comment, I cannot post comments yet (need 50 rep).
I've got a really strange error and any light that anyone can shed on this would be greatly appreciated.
I made some changes to some VB6 source which builds a COM object. The automated build which builds our app returned an error. No problem I thought--I'll just back out my changes. Well backing out my changes isn't making the problem go away.
Specifically when I attempt to build the app via a .vbg file, with a command line like path\to\vb6\vb6 ProjectFile.vbg /make
I get a message
"Compile Error in File '', Line : Object library
invalid or contains references to object definitions that could not be
found."
As I said, I reverted the source code so I'm really stumped as to why this error is still occurring. Any VB6 gurus around who might be able to point me at an answer?
I can post the exact code in question but the fact that it was building correctly, stopped building correctly and now refuses to build correctly makes me think this is not a problem with my code but rather some problem in the environment. Like something got put in the registry as a result of the previous build error.
Any tips, hints, or suggestions greatly welcome. I realize my question is a bit sketchy but I'm not even sure what's important to include and what isn't.
EDIT 1:
Thanks for the excellent suggestions guys. I think it is something to do with VB6 doing some sort of auto-registration.
Just to add a bit more detail: this problem does not occur when I build the referenced vbp file from the IDE. It only happens on the make on the .vbg which contains the vbp. Also the build tool in question automatically pulls latest source and the error happens on both my local box and the dedicated build box.
EDIT 2:
Hi again all,
The release engineering fellow figured out how to get this to build in his build environment so it's currently ok. Once we're past this crunch, I'll try to interrogate him about what he did and share the details with everyone.
Thanks again for all the great suggestions. This is what's so great about SO; that is, I asked about a 10-year-old technology and I got several great and on-point ideas.
Make sure that the VBG and all the VBP's got rolled back as well. That error is consistent with a project trying to reference a CLSID that is no longer valid for the dependency. Have you tried loading up the project group and building from the IDE, if that works and you save and check in all the changes to the group and project files, you might be fixed up.
I'm guessing the fact that you mention that it was a COM component might be the source of the problem. If any of the public method's or properties have changed then I seem to remember that VB6 will change the interface GUIDs and auto register the new ones.
My suggestion would be to check the registry to look for any mention of the component name, make a note of any associated CLSIDs, back up the registry, and then delete the references.
As cmsjr mentions it could also be a bad CLSID reference in your .vbp files.
The other option is that the failure has caused a problem with some .tlb (type library) or olb (object library) files.
The best thing to do is move all your compatibility DLL to a separate and combined directory. The reason for this is control over what VB6 is using to check for binary compatibility. In addition the Typelibs that are generated IMPORT the references. So if you using Binary DLL Ver 10 for compatibility however the import is pulling in Binary DLL Ver 9 you will have issues. By keeping all the libraries in a single folder and pointing your projects to the DLLs in that folder you ensure that the respective TypeLib Import the correct version.
Finally if you have multiple levels of DLL reference each other. You may run into mysterious error where the VB6 is unable to compile using binary compatibility. In such cases you need to compile the lowest DLL in the hierarchy (Utility DLL perhaps) copy it over into the compatibility folders. Work your way up the chain until everything compiles in one shot again.
This is because if have DLL A reference DLL B which Reference DLL C. VB6 will get sometimes get confused if you make a change to A and C. will compile fine but A will not until the compatibility libraries are updated.
Hunt down and delete any .obj and .exp files that may be lying around from the previous failed build.
You will have to open the project & re-type in the lines that you changed.
Save the project alongwith VBG and re-compile after that.
I think that will fix it.
EDIT: The idea is that the cls/bas file remember the class (CLSID) that you used. So, if you change the references but don't change the lines in the cls/bas - it is a mismatch of type (what was referenced vs what is typed in cls/bas file).