I'm having trouble using macros in my .inf file that I'm using to create my cab, specifically when setting the InstallDir string. If I do something like this:
InstallDir=\<PathToProgramFiles>\MyAppName
then everything works fine. However, if I do this:
InstallDir=%CE1%\MyAppName
then I get the following error when trying to install the cab (double tapping it on my device): "MyAppName was not installed successfully. Please run Setup again."
This only seems to apply to the built-in macro strings. I can use %AppName% without any problems. Maybe there is some registry setting that isn't properly set that would normally resolve the %CE1% macro?
Any ideas about what is going on?
Edit: My device doesn't have a \Program Files directory. It seems the %CE1% macro always resolves to that path and if the InstallDir specified in the inf file doesn't exist (with the exception of the last directory portion then the install fails. Manually creating \Program Files fixed the issue. Since a lot of the devices I'm working with have different paths for their Program Files directory, is there a generic way to get the installer to default to the actual Program Files dir? I guess my only other option is to not specify a path and force the user to choose one?
First, in this link you can find the shortcuts and their meaning (the %C..%), goto appendix B. The Windows CE5 MSDN link.
You can add a Setup Dll to your CAB installaer that will check the directory structure and will create a folder in case it does not exist. You may find this SO question useful.
A warning: If you are targeting regular Windows CE devices, beware where you place the files as it can be to a RAM based file system and then the files will disappear after reboot.
Related
I have a Visual C++ for Linux project in VS2017 that I'm building on a Raspberry Pi running Raspbian. This project consists of a single source file (main.c) and an image (test.jpg). When building the project, I want the image file to also be deployed to the pi, so that the code in main.c can do something with it locally. However, I can't figure out how to do this
The image file's Content property is set to True, as is Included in Project. In the project properties, under Copy Sources, Sources to Copy is set to "#(SourcesToCopyRemotely)" and Copy Sources is set to "Yes". However, when I build, only main.c is copied to the Pi, and the compiler output is just a single .out file. I hoped to also see test.jpg there, but alas.
This article mentions that #(SourcesToCopyRemotely) defaults to all files in the project. However, when I evaluate the value of #(SourcesToCopyRemotely, it evaluates to just "main.c".
How do I make sure content files in my projects also end up in the build directory, along with the .out file? Preferably without having to manually enter each filename in a post-build step.
It turns out this is a bug in VC++ for Linux. A workaround, currently, is to use Additional Sources to copy. There's a caveat though: it doesn't work with remote paths that start with ~. So you can't use $(RemoteRootDir) if the Remote Build Root Directory setting is set to the default of "~/projects".
I've currently got Remote Build Root Directory set to "/home/pi/projects" and for each file I want to copy to the build directory I set Additional Sources to Copy to "[filename]:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$Configuration)/[filename]". For instance:
firstimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/firstimage.png;secondimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/secondimage.png
Right-clicking on the non-source code file to open it's properties page and flagging as Content in the General tab will cause the file to be copied to the remote. There is no need to add anything to the Copy Sources tab. The Copy Sources page of the project properties must show the default of #(SourcesToCopyRemotely). And when you edit this setting the macro should show an expansion with the additional files included.
I have found that it necessary to refresh the macro by clearing Source to Copy and then restoring it to the default after you have marked the additional files as content.
I have encountered problems when the additional files are not in the same folder as the C++ source files on the Windows host and/or you want to put them somewhere else on the remote. There are several open issues on the VCLinux GitHub site like this one so it will be worth reporting any problems you have on there.
[VCLinux 1.0.6 on VS Pro 2017 + Debian Jessie remote]
The "Pre-Build Event" section of the project properties offers "Additional Files To Copy". Addressing my file there (relative to the solution) showed following in the output when building:
Copying file 'C:\myfilepath\resource.png' to '/home/pi/projects/myproject/resource.png'
It is possible to move the files to the final destination then with Remote Post-Build Events (mv source destination). Not the most elegant way, but the first thing I got working..
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.
I am trying to edit the corflags file so that I can run 32bit applications on a 64 bit pc but everytime I try to edit the file using something like corflags.exe assembly /32bit+ it comes up with the error message cf001 could not open file for writing.
Now I have tried a lot of different options such as:
Running in administrator mode;
Finding the file using a search and checking read only is not ticked
Checking that user full control is ticked
Tried to set the whole folder to non read only
When trying the whole folder, it goes through looking like it has set read-only, but then I click OK and re-right click on the whole folder, the box is filled in (not ticked) does this mean that part of the folder is read only and why does it reset to read only?
I just faced the same problem and have tried the same things.
Run cornflags from an elevated ("Run as administrator") Visual Studio Command Prompt. I did the same for a copy of the original .exe just to make sure no other process was using the program.
Create a copy of the file you intend to target with CorFlags.
(e.g. "WcfServiceHost.exe" --creates--> "WcfServiceHost - Copy.exe")
Rename the original file to something else:
(e.g. "WcfServiceHost.exe" --> "WcfServiceHose_Original.exe")
Rename to copy to the original file name
(e.g. "WcfServiceHose - Copy.exe" --> "WcfServiceHost.exe"
For my purposes, I created copies and named them describing their configuration:
Example:
WCFServiceHost_With32BitOn.exe
WCFServiceHost_With32BitOff.exe
Now I can destroy the WCFServiceHost.exe files and create them from these pre-modified copies. No more CorFlags operations necessary.
Note: this is basically a more verbose version of #RMalke answer and that answer should be marked as the answer.
I realise this is years later, but for anyone else looking, I found that the quickest way was to copy cmd and corflags.exe into the same folder as the one you want to edit. Then run cmd as admin from there.
I am having problem with implementing LibSVM to MATLAB.
I am using MATLAB R2009a (I also have the latest version, R2012b, but I dont use that one)
I downloaded LibSVM package, libsvm-3.14 to my Windows 7 PC, which MATLAB and OCTAVE interface come together.
I extracted the folder I downloaded. Which, below, you can see the printscreen of what the folder has in.
Where should I put my libsvm-3.14 extracted folder ? Should I put it under "bin" folder of my MATLAB installed in the directory?
C:\Program Files\MATLAB\R2009a\bin
I did that, however, it didn't work out. I will be grateful if you help me clearly. I just read README file, but it's not clear to understand and there is no other instructions online on the internet.
For the time being, it does not matter where you put that folder. You'll have to compile the Matlab-MEX files, from the source code that resides in the matlab subfolder of your extracted libsvm package.
Below, I will call the libsvm-3.14 (for example: C:\libsvm-3.14) extracted folder ROOT (so replace ROOT wilth C:\libsvm-3.14 below).
So, fire up Matlab and, then, at its command prompt, type:
cd ROOT
cd matlab
make
Now, in the ROOT/matlab folder, you should have obtained two MEX files (with the .mexw32 or .mexw64 extension). These are the files that you will use from now on. You can discard the rest, except those files (and, maybe, some other generated libraries).
According to the Makefile (that is ROOT/matlab/make.m), the MEX files are called svmtrain and svmpredic (+ the extension).
So, next step would be to create a subfolder called libsvm/ under your's Matlab/toolbox folder, copy the two MEX files therein and, then, add that libsvm/ folder to the Matlab Path (not the Path of your system, but of your Matlab installation).
Then, by typing:
svmtrain
and
svmpredict
you should have the help (usage) of these two functions.
With the aid of #axeoth, here is the solution. I followed instruction files in matlab subfolder of extracted libsvm package. I downloaded and installed Microsoft Visual Studio 2010 and wrote 'mex -setup' on command window of MATLAB to choose a suitable compiler for mex (I use MATLAB R2012b in 32-bit PC, so I found supported compilers in this link http://www.mathworks.com/support/compilers/R2012b/win64.html) After then, I followed #axeoth's instructions. I changed the name of the folder to ROOT and moved it to Documents/MATLAB. I started MATLAB and on command window, I wrote these below "one by one"
>> cd C:\Users\HUstat\Documents\MATLAB\ROOT\matlab
>> cd matlab
>> make
then I copied everything obtained in ROOT/matlab subfolder. I created a new folder named libsvm under MATLAB/toolbox folder and pasted everything there. and then, I added that libsvm/ folder to the Matlab Path by using "Set Path" button on MATLAB R2012b. After then I wrote "svmtrain" and "svmpredict" so I got the helps of these two commands.
For those having major compiler problems I thought I'd leave some extra information on the subject of installing compilers. This was a frustrating problem I had an ended up contacted MATLAB for help. I would have commented in the above posts but I do not have enough "rep" so here it is:
I was unable to install Microsoft Windows SDK 7.1, whether via Microsoft Visual Studio 2010 or otherwise. I found out that this was because I had a certain version of Microsoft Visual installed (version 10.0.04... was the cause of the problem for me). The work around was to uninstall Visual, install SDK 7.1 independently and then re-install Visual after. The process is written up in greater detail in the link below:
http://www.mathworks.com/matlabcentral/answers/95039-why-does-the-sdk-7-1-installation-fail-with-an-installation-failed-message-on-my-windows-system
It may also be that you have the compiler installed but that it wasn't recognised until MATLAB "found" it. This happened to me after the re-install. To check if you have the correct compiler and "find" it run mex.getCompilerConfigurations('Any','Installed') to get a full list. Then do mex -setup using the SDK 7.1 choosing the C/C++ version over FORTRAN.
I know the question is answered already but hopefully this may help someone the same predicament I had.
I find increasingly now when I am building a large project, I get the following error.
fatal error C1083: Cannot open
compiler intermediate file:
'C:\Temp\SYS\a03132ex': Permission
denied
It occurs in Visual Studio 2003 and VC6, and I have investigated the potential MSDN reasons and drawn a blank. There is plenty of space on the hard disk, and not that many other programs open that I should be running out of handles. Any ideas, or is it time to re-install windows again. I'm running XP SP3 by the way, and have two large NTFS hard disks with very many files.
Edit: the name of the temp file changes, and I have cleared out the entire c:\temp folder.
I seem to remember from somewhere deep down memory lane that deleting the temporary files created by visual studio for the project fixes this issue (until it pops up again).
The temporary files have the same name as your project. (There may also be something VC/VS related in your home directory if that does not help.)
And if that doesn't help, check if your TMP environment setting doesn't end with a semicolon for example. It should be a fully qualified path as well, not relative.
Edit: I found a topic on the internet about it and there it is said that if you attempt to include a directory instead of a file you can trigger that very same error.
I assume you already verified this, but does the actual C:\Temp\SYS folder have the correct permissions (ie allow all users to read/write files in it)?
You could also check the rights associated with c:\temp and c:\temp\sys (if sys does exist outside the compilation session)
cacls c:\temp
Also, (as suggested here), try setting the compiler flag -Bd under advanced options and inspect the arguments into the compiler. Maybe you meant to specify a path and end up compiling a non-existant file ?
Keep your temp file location simple, for example when I copy projects from my laptop to my office PC the VS2003 project didn’t compile.. The “tmp” system variable was pointing to %USERPROFILE%/TEMP. Visual studio 2003 was giving few "Fatal error C1083: Cannot open compiler intermediate file:" errors
I made a new Temp folder on C drive and change the system variable TMP to "C:/TEMP". Recompiled the program and Voilà no errors!
do not click Rebuild button in complier, click Build button only - this solve my problem
I had exactly the same issue. Disabling the antivirus while building the project solved that issue. A possible permanent solution would be to setting VS's temporary directory somewhere else and telling the antivirus to exclude that directory.