I have created a Nodejs application (sdgnodeapp) in my OpenShift domain, and was trying to import the sdgnodeapp application using OpenShift Explorer into my empty workspace in JBoss Developer Studio 7.1.1 GA .During the Import-Application workspace, I specify the git-clone-directory to be the same as my workspace-directory, JBDS then throws an error
"Could not import project to the workspace.
Invalid project description.
OK
/Users/sddasgu/SDGDevCode/Node/NodeWorkspace/sdgnodeapp overlaps the location of another project: 'sdgnodeapp'".
NOTE: If I change the git-clone directory to some other directory (not my workspace-directory), then the project is added to my workspace as expected.
I am used to creating projects inside my workspace-directory, but it seems to me in the above case, that the git-clone happens successfully, but then then the project creation fails. Is there a way to circumvent this problem ?
This is caused by there already being a directory called 'sdgnodeapp' in your eclipse workspace. Rename the existing one directory on your machine in your workspace to something different and then run the clone command again. That should fix it
Related
I cloned an existing repository (repository created by a team in my office which deals with subscriptions in a certain app we are working on) which have some database migration files inside the path ..\internal\db\migrations , this is migration files path.
First of all i run the command docker compose up .for an existing docker.yaml , then i run the command go build then go run . .
I made a debug and the app reaches the point when it is about to run the migration file then it displays an error:
Failed to initialize App. Error: first D:\subscription-store: file does not exist
although I checked the paths through debugging and they are correct and at the same time the migration files all are exists.
I am using visual studio code as an editor, Go version 1.15 ,docker and MySQL. I am running on enviroment windows 10.
After debugging and searching , it was found that the repository uses some paths to get the migration files from the local drive . the paths was written for Mac in the code base and i cloned the repository on a windows machine so it didn't work .
The error specifically happened in the call of the function
migrate.NewWithDatabaseInstance(
fmt.Sprintf("file://%s", fullPath),
"mysql",
driver,
)
The generated path for the first parameter was
file//d:\\subscription-store\\....\\db\\migrations
And this is wrong for windows as the driver d: shouldn't be supported in the path .
it is resolved as following
"file:///"+"subscription-store\\....\\db\\migrations"
When the above URL sent to the function rather than the old one , it worked successfully.
I've been working with SSIS reading different files - from CSVs to XLSXs - with no problems. My paths are relative, so SSIS searches for the files from the project's folder.
Well, today my colleague tried to run a package and he got a curious error message saying that the file could not be found under the "C:\windows\system32" folder. There's no configuration that would point SSIS to that folder and with me and a third colleague it's working well.
After some investigation we discovered that the problem has nothing to do with the user itself, but with how the user opens the project. Since the beginning I've been opening the project by double clicking the ".dtproj" file. My colleague first opens the SSIS development interface then opens the project file from the menu.
Has anyone noticed that behavior? What could be the cause for that?
error message print
Microsoft Visual Studio 2008
Version 9.0.30729.4462 QFE
Microsoft .NET Framework
Version 3.5 SP1
Installed Edition: IDE Standard
This happens because the different ways of launching the IDE end up with different current directories for the IDE process. You can test this by creating a package with only a Script Task, with the one line:
MessageBox.Show(Environment.CurrentDirectory);
And then running this project after launching it both ways.
Double-clicking the project or solution file sets the folder containing that file as the current directory. (I assume this is standard Windows process launching behaviour when starting a process based on the file extension association.) SSIS packages then look in the current directory when the path to the configuration file is relative.
We use relative paths to configuration files all the time to simplify deployment, and have to always remember to open the solutions by double-clicking the SLN file.
We have downloaded and installed a running instance of Wirecloud in our company server following the steps at:
https://conwet.fi.upm.es/wirecloud/install
We created the instance using the --quick-start command to try the instance, and ran wirecloud using the Django internal web server with the following command:
$ python manage.py runserver 0.0.0.0:8080 --insecure
We are able to enter the instance, and move around the enviroment, but we have encountered a problem when we try to upload a widget to our local workspace. After I search for the widget in my computer (previously downloaded from the Fi-lab marketplace), we get the next message:
Error adding packaged resource: Internal Server Error.
We also tried to download the zip file of the widget from github, unzip it and recompress it as a wgt file (compress as a zip but changing the extension to .wgt) and we get the same answer from our wirecloud instance; but if we try to upload the same package to the instance in fi-lab, it uploads successfully.
We don't know if it's because of the quick-start installation we made or if we have to modify something from our widget files in order to be able to upload it to our local instance.
Solved
The problem was in the config.xml file: the name of the attributes and the structure of the widgets unable to upload were different from the template of the config.xml file posted at the users guide.
After changing it to follow the structure of the template it works fine.
My widget example was the NGSI Updater. The thing is that it uploads perfectly in the instance at FiLab, even though the config.xml file had a different structure from the one of the template; but it encounters an error when uploading it to the Wirecloud local instance at my server.
We are trying to configure a deployment of ASP.NET application using Octopus deploy.
All is working fine, but sometimes the step fails while trying to overwrite files saying the the file is already locked by some other process.
We already stop IIS before the deployment starts, so not sure what we can try here.
Sometimes the error is in the application customlog folder(txt files), sometimes its in the bin folder for some dll etc.
Exact error is:
*Unable to copy the package to the specified directory 'D:\Apps\XYZ_Stage'. One or more files in the directory may be locked by another process. You could use a PreDeploy.ps1 script to stop any processes that may be locking the file. Error details follow.
Access to the path 'D:\Apps\XYZ_Stage\bin\XYZ.Business.dll' is denied.
System.UnauthorizedAccessException: Access to the path 'D:\Apps\XYZ_Stage\bin\ACA.Business.dll' is denied.*
Any suggestions?
If you're using Octopus 2.0 or higher, you can leverage the "IIS web site and application pool" deployment option which causes Octopus Deploy to handle all the complexities of deploying to IIS without you performing manual steps.
Here's some information: http://docs.octopusdeploy.com/display/OD/IIS+Websites+and+Application+Pools
I am trying to build a Visual Studio Package project via Hudson CI. This is a Visual Studio 2010 project. The project builds fine in my dev box, but for some reason, I keep getting the following error only when building in Hudson:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets(378,5): error : Error trying to read the VSIX manifest file "obj\Release\extension.vsixmanifest". The system cannot find the file specified. (Exception from HRESULT: 0x80070002) [C:\hudson\workspace\MyProject_Daily_Compilation\Source\MyProject.VisualStudio\MyProject.VisualStudio.csproj]
I have verified that the file exists on disk in the following location:
C:\Hudson\workspace\MyProject_Daily_Compilation\Source\MyProject.VisualStudio\obj\Release\extension.vsixmanifest
What could be causing this issue?
You are likely to experience such error if the user you are running your build as does not have administrative privileges.
So there are 2 solutions:
1) Run your build (build server) with administrative privileges.
or if you can't really change the user your build server is running on
2) and you actually don't need to deploy the VS extension on the build server itself, set the DeployExtension property in your *.csproj file to false.
Microsoft.VsSDK.targets sets that property by default to true
<DeployExtension Condition="'$(DeployExtension)' == ''">true</DeployExtension>
but if you don't need to deploy that extension locally (but rather would prefer to get the *.vsix bundle built you can safely put
<PropertyGroup>
<DeployExtension>false</DeployExtension>
</PropertyGroup>
The original error is basically happening because the attempt to get the deployment path fails at some point in the build and disrupts successful vsix package generation. By setting the property to false the build doesn't attempt to deploy the extension locally (but a valid *.vsix is generated)
I am guessing you running hudson as a service. If so the "0x80070002 - The system cannot find specified file" could well be due to the user being used to run hudson does not have access.
The quick solution to this is change the "Log on" user for the Hudson service to be your normal account.