Got a strange problem with Antenna - I've recently switched over to a new laptop, and now when I copied my build setup across to it it started exhibiting strange behaviour. When I call wtkpackage (in a way that worked perfectly fine on the old laptop with exactly the same codebase), the generated JAR file contains two META-INF/MANIFEST.MF files (yes, exactly the same file path). These seem to have the same contents, and from the output from the command-line unzip tool (unzip -l myscrewedup.jar) one appears at the start of the file, one at the end. I've tried adding the duplicates="fail" attribute to the package command, but with no joy.
Has anyone else encountered this? If so, did you find a solution?
Better answer this one in case anyone else does encounter the same problem. The problem was with the Ubunutu 11.04 setup I was using on the new laptop - for some inexplicable reason, the jar command was linked to fastjar, a C implementation of jar which evidently doesn't work properly. Switching this over to the standard Sun implementation fixed the problem immediately.
Related
I've tried to install Monodevelop-Stable on Arch-Based Linux ( Manjaro ) and i'd fault 3 times, it wasn`t possible to build from Github sources or from AUR or Flatpak, so i decided to use monodevelop-stable-bin also from AUR, but when i tried to run my app , i got this problem
"$(MSBuildBinPath)\Microsoft.CSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk (MSB4019)
Another words:
"MonoDevelop/7.0/MSBuild/2472_1/Microsoft.Csharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk (MSB4019)
But i have in my directory:
Microsoft.Csharp.Crosstargetting.targets
Notice , that this answer also wasn`t helpful:
this one
Question is indeed so popular on the internet , but i still haven`t found an answer , and i need some help
I have the same problem, I talked a bit more in detail in this answer, but the short of it is that, for now, it seems that there is no way to use Monodevelop on Arch based systems.
I recommend using a Ubuntu based distro for programming (there are many other similar problems with Arch). There Monodevelop should work just fine.
Of course, you can try to use other IDEs, like JetBrains Rider (I haven't personally tested it) or just use text editors with appropriate extensions, like VSCode or Atom.
I'm pretty new to InstallShield - so bear with me.
I have created a Basic MSI installer that correctly installs our application and, until recently, every time I rebuilt it (with some new files for a new build of our application), it would replace the files with no issues.
However, I rebuilt it this morning with a new version, it flat out refuses to replace any files.
For example, out main exe now has a file version of 8.0.0.15, the one it is replacing is 8.0.0.13; the new modified and created date is 7/11/2013, the one it is replacing is 6/26/2013 for both - it still wont replace the old file with the new one (this is just 1 file in hundreds, but is the main exe and so it definitely gets changed with each release).
I have changed the properties of our own exe's and dll's to 'Always Overwrite' under 'Files and Folders' to no avail (I haven't touched the 3rd party dll's since they never changed).
I have changed the ResintallModeText to 'asum' to no avail - should I try 'asumv'?.
Before I have the application completely uninstall itself prior to reinstall, is there anything else I should be looking at to try and determine what may be preventing the installshield from replacing the files on the target machine?
I have no idea what could have changed to cause it to stop upgrading - we haven't had to make any changed to the installshield for some months since everything was running fine.
If you need logs or anything, let me know (though I can't get it to write out the installshield verbose log on install - but I can provide the Windows installer logs).
Thanks for your help!
Thanks to the comment from #anand which solved my problem as well. In my case, the executable was not updating even when I updated the product version (i.e. 1.0.001 to 1.0.002) and changing the package code for a new build.
The solution for me was to right-click on the executable in Files and Folders (in InstallShield) and select Properties. After checking "Always Overwrite" my executable now gets updated regardless of the product version or package code.
After automatically upgrading the project file for a .Net 4.0 web application to work with Visual Studio 2012 everything worked ok at first however when compiling I got lots of errors like this:
Description : Source File '..\..\..\..\..\File Path' could not be found
File : CSC
And when trying to build using MSBuild (passing just the project full path, with no additional parameters) in the "Developer Command Prompt for VS2012" I got basically the same errors:
"CSC : error CS2001: Source File 'x' could not be found"
All errors refer to Linked Files (aspx,cs,etc) located in other web applications projects located at a different deep in our code Branch (that's why all the '....\' at the beginning of the paths)
To me it looks like a problem with the file Length, I had the same problem a while ago when building the projects on our CI server using MSBuild, I was able to manage it by manipulating the project files before building them using a custom script without the need to move the branch around or reduce the deep of the projects, I didn't have to move anything, the important thing at the time it was that developers using Visual Studio 2010 could compile everything without problems. I learned by this that compiling/Building with MSBuild was different that with DevEnv/VS, and for example MSBuild didn't support building Setup projects and DevEnv did.
Since this is happening now with VS 2012/DevEnv 2012 , plus that VS 2012 doesn't support setup projects anymore (like msbuild), plus VS/DevEnv have the same problem with the file length, it looks like VS 2012 its finally using msbuild under the hood or are more tightly integrated, however I didn't find any article to confirm this.
Changing the branch structure/changing the deep of the projects it’s not an option right now due to several reasons (large code base, high number of projects, risk, timing, effort, etc.).
Does someone have an alternative solution or a fix for this issue in Visual Studio 2012?
Regards,
P.D.: BTW I already checked this post MSBuild error with linked files but like I said before changing the paths its not an option right now.
Try getting the Build Logs,
http://msdn.microsoft.com/en-us/library/vstudio/ms171470.aspx
it seems that csc task could not find the source file. One cause it you import the wrong file.
so you have to edit the project file via normal Text Editor.
I found a solution to this issue, when you linked the file, you relative path is recognized by msbuild and go back from there it become your path in a long path however you can change it in the project definition doing right click/unload the project/ and change the path from ../../../ to $(SolutionDir)/../.. until find the file to link, note: it's extend the character from 255 to 300 character.
Check that you have the latest version of the linked files from the other projects. Visual Studio will NOT automatically get them if they belong to another project.
Check that the linked paths are indeed correct. You can monitor what files VS.NET and MSBUILD are trying to access with the help of the SysInternals ProcMon tool (filter on process names and filter out all successes)
If you suspect that the path length is the problem (this will also be visible in the ProcMon tool), you can try to shorten them by linking to the absolute path (C:\X\Y\Z) instead of a relative path (......\Z). The location of the linked files can then remain unchanged.
My 2 cents to this problem... In my case, I had a file created in one project (i.e. ConfigModel) and I had a link to this file in another project but when I renamed the file ConfigModel in the first project to LoginModel for example, it didn't rename the link in the second project causing this error to occur.
I know that i did this question a while ago but for what is worth, The approach that we finally went for was:
Locating the files that were reported as too long.
Reduce the full path length of those files, by reducing the length of the name and/or
the length of the container folder or reducing the folder nesting
level. Therefore reducing the full path length.
Update the links of the changed files (re-linking) on the dependant projects.
This solved the problem with Visual Studio 2012 on developers workstations and on our CI/Deploy servers that used MSbuild.
For my scenario this approach was less risky,and implied less effort than moving complete projects/solutions to reduce their folder nesting level or reducing the folder names, and have to update all the references of the dependant project/solutions.
Ok, I hit this and solved it today. I found it by following a msdn tutorial (https://msdn.microsoft.com/en-us/library/ms379563%28v=vs.80%29.aspx) and here's the command that broke for me:
csc /t:library /out:MyCodeLibrary.dll simpleType.cs
Giving me the message
error CS2001: Source file 't:librabry' could not be found
Which worked after changing the original command to the following:
csc /target:library /out:MyCodeLibrary.dll simpleType.cs
I'm not sure why the short version of the /target flag causes this error, but I've not found anywhere else online noting this cause specifically so I wanted to record it here.
This problem arose for me when I reverted to an earlier version of a git repository. Apparently I didn't add the project file to the repo so when it reverted it didn't revert the project file also. What I did to clear it up was to exclude the missing .cs file from the project by clicking on the missing file in the project Explorer. It was easy to find since it was marked with a warning triangle. Then rebuild the entire solution.
Verify whether the files mentioned in the error do not exist in the corresponding folder.
If their non-existence is intentional, edit the .csproj files and remove the reference for those files.
Build again.
I inherited this issue from a project somebody else was working on, in my case was a .cs file supposed to be generated by an Entity Framework .tt template, but for some reason it wasn't, so the compiler was going all CS2001 about that. I had to update the template and manually run it, everything worked after that.
this is the first time I'm encountering this kind of issue.
I have a perfectly working code that runs without any issue under 3 different platforms (Win/Linux/OS X).
However after the deploytool compilation a part of it stops working. How can I get the error once the code is compiled!? It seems that it has some problems in loading and reading .mat files. Is that possible?
I hope someone can help me.
Thanks
edit:
I've solved the problem! Unfortunately was all addpath fault!
I have a lot of folders with files and functions that are needed for running the code, after the compilation matlab does a mess with all of that folders.
Good hint: do not use addpath for the compilation! Thank you anyway!
You can try to catch the error and write it to a text file. Or build in a check that prints text to the screen.
A bit more in general: You can try to isolate the part of the code that has the problem, and then basically cut out half of the functionality in this part repeatedly until you have exactly found the source of the error.
For no reason that I can see, I can no longer run a TortoiseSVN Update on a development directory on my portable Windows XP Professional SP3 machine, getting the error:
Previous operation has not finished; run 'cleanup' if it was interrupted
Please execute the 'Cleanup' command.
If I try running cleanup, I get another error,
cannot process the following paths: cannot move $ROOT_DIR/.svn/tmp/tmp-... to $ROOT_DIR/path/where/thing/should/go: no such file or directory
I have verified that both files exist, and actually from CMD.EXE prompt I am able to issue a MOVE with those two filenames and have it work correctly. It's no use because next time SVN tries to repeat the operation itself after creating a different tmp file name, and while CMD succeeded, SVN fails.
UPDATE: the path lengths are in both cases well below PATH_MAX, target file system is NTFS, and permissions are OK. Maybe I'll now try with FileMon to see whatever TortoiseSVN is really up to.
I tried downgrading TortoiseSVN but to no avail. Other repositories work OK between the same machines.
TortoiseSVN 1.7.9, Build 23248 - 32 Bit , 2012/08/30 18:25:37
Subversion 1.7.6,
apr 1.4.6
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.1c 10 May 2012
zlib 1.2.7
Both server (OpenSuSE Linux 12.2) and client now run the latest version of SVN.
On Windows, I also cannot seem to get any more informative logs or information (I'm not very skilled with TortoiseSVN, I have always used the Linux command line version).
I might delete the local copy and run a checkout, but it's about 2 GB of data, and I'm on a slow connection, so it is really more of a "fly physically to server location and hook a copper Ethernet to the local network there" alternative. I'm reserving that as a sort of last ditch, nuclear option; I'd really rather understand what the problem is, for I fear it might happen again.
UPDATE
I've tried to delete remotely the subdirectory involved, committing the deletion on the server; deleting the subdirectory locally, and emptying the .svn/tmp subdirectory where I found sixteen tmp files, all copies of the one PNG causing problems.
I am still not able to perform any SVN subcommand, getting "Run cleanup!" error; on cleanup; I get a failed attempt to copy a tmpfile to the never-sufficiently-damned .PNG file, which no longer exists anywhere, into a directory that no longer exists anywhere.
I tried recreating the directory locally (but not the file!), no changes.
With FileMon, I traced the source PNG to 8e4c2389cf9d85c8b8ee54d49ea053c752a38187.svn-base in .svn/pristine subdirectory, tried removing it and got SVN complaining. I tried copying it to its intended destination (so that the file-as-it-should-be and the file-as-it-is are identical), no joy.
UPDATE
Well, this is weird. I decided to track everything that TortoiseSVN is doing using FileMon. I could see it checking the wc.db and search the item, checking for it in .svn/pristine (and finding it), copying it (unnecessarily if you ask me...) in .svn/tmp, and finally checking $DESTINATION_FILE (with correct case) using Windows Open() API. And getting PATH NOT FOUND. Yet the file is there, I can see it (and the name is less than 8.3 characters). And why PATH not found and not FILE not found?
Okay, it all boiled down to a directory that had been created remotely with a name ending with space. The file in itself was OK; the directory where it stood was not.
When updating, apparently, the directory got created but the name was shortened by Windows to exclude the final space.
To add to the difficulty of diagnosing, while TortoiseSVN did tell me what the problem was, it did so in the dialog box where the Arial font made the space in \path\to\your \file not clearly recognizable (it was, once I knew where to look, and compared that slash with the others. This one stood a little farther from the letter at its left).
Lesson learned: check really carefully the dialog file name, character by character (note to self: find a way of having it in Courier New if at all possible).
You may have two files in the repository that differ only in case. That's a problem on Windows. See this FAQ for details.