I'm new to C and installed necessary extensions for C but whenever I try to run a simple program I get this error:
"Unable to resolve ${workspaceFolder} in configuration ("workspaceFolder")"
Any solutions in simple terms ?
Some answers on here said to change the path of the workspace folder but I don't have a workspace folder. Some other answers said to not save into OneDrive. The file was saved into OneDrive but another made wasn't and the same issue persisted
Related
I attempted to install the Traffic library for the book "A Touch of Class" but was not able to compile the examples. EiffelStudio complained about a base2.ecf file.
Error code: VD00
General configuration parsing error.
What to do: fix the configuration file.
Could not open file: \base2.ecf
$EIFFELBASE2\base2.ecf
base2.ecf is found in where Windows installed Eiffel: C:\Program Files\Eiffel Software\EiffelStudio 18.11 GPL\unstable\library\base2.ecf The offending line of code seems to be this in the Traffic configuration files:
I have attempted to change this configuration file pointing directly to where the file is, using the actual path, to no avail.
Setting the variable EIFFELBASE2 might help:
set "EIFFELBASE2=C:\Program Files\Eiffel Software\EiffelStudio 18.11 GPL\unstable\library"
Then, EiffelStudio should be started from the environment where the variable is set.
(However, I wonder if this is the library to be used with the examples, or if there is another one that comes together with the examples.)
I've been working on trying to figure out why our auto-generated deploy.cmdscripts will not work when installed to C:\Program Files (x86)\OurProgram. I finally narrowed down the issue to the closing parenthesis in (x86) as the script would terminate with "Files was unexpected at this time". One possible solution was to manually create another batch file to set _DeploySetParametersFile to a Windows path ( C:\Program^ Files^ (x86^)\OurProgram\Program.Parameters.xml). This isn't a valid solution for me, so I dug into the auto generated file and found the issue to be 2 variables:
RootPath
_DeploySetParametersFile
Both of which were referenced using %'s(i.e. %RootPath%), however as soon as they were changed to !'s(i.e. !RootPath!), no 2nd script was needed and I can run the cmd script from Program Files (x86) just fine. The issue of course with this is, the deploy.cmd file is auto-generated on each build, thus I have to change it for each build I do. My question is this: Is there a way to edit the template Visual Studio uses to generate the deploy.cmd file? If so, where? It seems so ridiculous that Microsoft would have this be an issue in their web deployment.
I'm facing a problem right now and I don't really know how to get more informations about it.
I've converted a desktop application through Microsoft's Desktop App Converter, made some manual modifications about the visual assets, and rebundled it through "makeappx.exe". Then I signed it.
Everything went fine. Except that when I double click the appx to check it, I have the following window:
Appx Error
Which roughly translates as "Couldn't open the appx or appxbundle file" and "Reason: Failure caused by an unknown reason".
This does not helps me a lot :/
However, if I try to install the package through a simple "Add-appxpackage MyPackage.appx", it works perfectly fine.
Could anyone help me find some leads on what's happening here? I've already checked the event viewer as explained here but I couldn't find anything unusual.
Thanks,
Skefrep
It seems the Microsoft team has taken notice of this problem and investigated this appropriately.
-Here is their solution-
The problem can be because when you convert an app with DesktopBridge the resources are signed with the manifest info and store that info in the .pri files you found in PackageFiles folder. Later, when you change something like the Publisher or the Name this signature doesn't match. To fix this you only need to recreate the .pri files.
rm *.pri. Remove the old .pri files.
cd C:\foo\PackageFiles\. Change current directory to the PackageFiles folder. This step is important for the next step.
makepri createconfig /cf priconfig.xml /dq en-US. Create a configuration file for the resources.
makepri new /pr "C:\foo\PackageFiles" /cf "C:\foo\PackageFiles\priconfig.xml". Generate the new *.pri files.
Then you can make the package as usual: MakeAppx, etc.
You can find more information about this problem in "Failed due to unknown reasons" error when you try to sideload a Desktop Bridge app - App Consult Team.
I'm getting errors when I attempt to run my project deployed to app engine. I see issues like:
java.lang.ClassNotFoundException: com.seattleglassware.AuthServletSupport$$anonfun$finishOAuth2Dance$1$$anonfun$apply$33$$anonfun$apply$34$$anonfun$apply$37$$anonfun$apply$40$$anonfun$apply$41$$anonfun$apply$42$$anonfun$apply$45$$anonfun$apply$47$$anonfun$apply$48$$anonfun$apply$49
The class name looks reasonable (well, for certain values of reasonable - this is code generated by the Scala compiler). I see the file in my local web/WEB-INF/classes/com directory and I can decompile it with javap (so I don't think it's corrupt or anything silly like that.) Everything works fine running on a local debug server.
Even more strange, I can pour all the .class files in web/WEB-INF/classes into a jar file like this:
cd to the web/WEB-INF/classes directory
jar cf ../lib/classes.jar .
And now, if I upload the project (pressing the deploy button in Eclipse), I don't see those ClassNotFoundException errors. Delete the jar file, re-upload the project, get the errors again.
I'm wondering if there's some sort of limit on the names of .class files? Or something else happening in the deployment process that's causing this to happen?
EDIT: running from the command line made this much more clear (using maven now):
SEVERE: Invalid character in filename: WEB-INF/classes/com/seattleglassware/AuthServletSupport$$anonfun$finishOAuth2Dance$1$$anonfun$apply$33$$anonfun$apply$34$$anonfun$apply$37$$anonfun$apply$40$$anonfun$apply$41$$anonfun$apply$42$$anonfun$apply$45$$anonfun$apply$47$$anonfun$apply$48$$anonfun$apply$49.class
But it still looks to me like that's a valid filename.
The inclusion of "special" characters in the file name may be the issue here.
There is currently an open issue regarding "special" characters in project file names.
Issue 2211: Special characters are not supported in the filenames in the project
The original issue was reported by a Python App Engine user, however if you look in the comments you'll see that it apparently affects Java users as well.
I am unable to build my Web Application (not Web Site) in our build environement. We use DMAKE in our build environment (this unfortunately is non negotiable, therefore using MSBUILD is not permitted ) and when invoking the asp.net precompiler through
C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler -d -nologo -p Site -f -fixednames -errorstack -v / Debug
We get the following error
error ASPPARSE: Could not load type 'X.Y.Admin.Site.Global
If I compile from the ide it is successful. If i then compile with aspnet_compilier it is successful. So i only get a successful compile with aspnet_compiler when the target dll i am trying to compile is in the bin of the web application i am compiling.
I keep running into postings that talk about solutions using MSBUILD which unfortunately I cant try.
Any help would be appreciated
We had the same problem on our web application:
error ASPPARSE: Could not load type '...'
The problem was that we had the file on disk (on the project folder) but it wasn't included in our application project (in the .csproj file). We solved the problem by including the file in the project :)
I ran into a similar problem using NANT. The trick was to compile the web applications code files into a dll then include that when using aspnet_compiler.
use the command line compiler,either csc.exe (c#) or vbc.exe (visual basic), to compile your web application with an output of type library. This will create a dll that you can use in your aspnet_compiler task
Have you tried specifying the path using -p? Sounds to me like it can't find that type / assembly.
http://msdn.microsoft.com/en-us/library/ms229863(VS.80).aspx
For web applications, you have to build the .vb files into a dll and put that in the bin folder before you run the aspnet compiler. Check the output window in visual studio and you'll see the command line for the VB compiler. Run that first before you run the aspnet compiler, and the asp pages should be able to find the missing types.
This problem was resolved for me by simply deleting all bin and obj folders. Seems like they were in a bad state somehow. I also deleted the the .sou file, but I don't think that was the issue.
I received the same problem.
I fixed it by copying my webapp's DLL from the OBJ/DEBUG folder to the BIN folder.
I just had this error and found 2 ways to fix it, either:
Change the Codebehind attribute in the global.asax file to CodeFile and add "partial" to the class declaration
In the deployment project's property pages, set "Version output assemblies" and provide a version number
I don't really know why either worked, but it did.
solution :
-p Site path must have the directory path of .csproj file location.
ex :-
aspnet_compiler -p D:\Projects\MGM\mgm\mgm -v / D:\Projects\MGM-deploy\mgm_compiled