Embed a part of a solution that accidently got linked from outside
I am not fully aware how all parts of a VB.net solution are interlinked.
When I wanted to work at home, I put files on a USB stick to continue there.
That didn't work at all.
Now my work is like a fallen cup: I got all parts but they don't work together anymore.
I can only build the project when the USB stick is connected.
Every attempt to get the file back onto the desktop PC has failed.
What can I do to get the file onto the desktop computer so the USB stick is no longer needed?
What I tried: copy manually (not working) and ADD EXISTING ITEM (not seen by Visual Studio)
Related
We have a C codebase which is around 9GB in size! It takes a lot of time (hours) to create the IPCH database/files and hence the intellisence doesn't work so well for the first few hours of the project.
Is it possible to index the whole project separately and use the resulting IPCH database for all our work spaces.
One more problem is that indexing is done only for those files which are clicked. We want the IPCH to be built for all the files no matter whether they are clicked or not.
We are using "Remote SSH" plugin and the system which we work on are essentially virtual machines but we have a facility of NFS mounts, hence we can mount those pre-compiled ipch stuff to all our virtual machines.
Please suggest the right workflow.
I am developing a data acquisition program in Labview that uses multiple translation stages, cameras, a high speed digitizer, and other instrumentation. I'm developing the application on one computer, and will be deploying it to another computer. The development computer has labview 2013, and computer the application will be deployed on currently has Labview 2012, but we will be upgrading it to Labview 2013 when we move the application over there. Some of the drivers need different versions of the driver to function under Labview 2012 than they do for Labview 2013.
I'm trying to keep all of the vi's, subvi's, and drivers for the instrumentation in one directory tree so that I can move the whole tree over to the computer it will be deployed on.
When I load the project in Labview I'm getting a lot of "Resolve Load Conflict" dialog boxes popping up. When I go to investigate, Labview says it can't find one of the files that is causing the conflict, but yet it popping up the dialog. An example is below:
This happens every time I load this project - saving all doesn't enter the new paths into Labview. I also tried creating a new project, and pulling these vi's in, but the new project has the same load conflicts.
Evidently Labview or these vis think that these vi's that no longer exist are still there.
How do I fix my project, vi's, or Labview so that it only uses the vi's that it should, and I don't get all of these conflicts, many of which are with nonexistent files?
I just had this same problem, but solved it like so:
In your project window, expand the Dependencies group. You should see each of the undesired subvi's listed there.
Right click on each one and select 'Replace with item found by project...'. This will bring up the familiar conflict resolution dialog box, go ahead and select the proper path and click OK.
Now, because the dependency has changed, Labview is going to change the dependency path that is saved in the calling VI. You'll see a save dialog asking if you want to save the changes to the VI(s) that is/are calling the dependency whose path you just changed. You want to save changes.
Do this for all the dependencies and you should be good to go.
I've found that when it is necessary to move driver files and libraries from the NI default locations, renaming the files prevents further confusion.
For instance if you have a "instr.vi" that you need to move to a custom directory location, renaming the file "my_instr.vi" and linking to the renamed file prevents future conflicts.
Of course, this may initially involve some amount of work in renaming all the files and then directing your calling VIs to use these newly renamed driver files, but after that initial time invest you shouldn't have any more problems.
Ì have had this problem in a number of projects and I have almost given up. I am sure there is a solution though. When I insert a Flash object in a VB.Net Windows Forms application, it works fine for a little while and then I see this error in the Design Screen. I am using Visual Studio 2010
Could not load file or assembly 'Interop.ShockwaveFlashObjects, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
I have read several descriptions of why this happens, and apparently it has something to do with strong naming (or lack thereof), but have not found a solution yet. I used Add Reference->COM->Shockwave Flash (C:\Windows\SysWOW64\Macromed\Flash\Flash32_11_2_202_235.ocx) If I ignore the error it appears to work fine, but I don't want my users to have a problem.
I know I can use a browser control and play the Flash in that, but for reasons I won't get into, I have to use a Flash control. Any ideas would help.
Okay. I can't promise this to work for you, but it worked for me.
First, you have to locate a file on your computer titled AxImp.exe. You have to run it from the command prompt. This file is located (for me at least) here:
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64
Once you do find and run it, you have to point it to the correct Flash.ocx file you're using, like so:
AxImp.exe <path>\Flash.ocx
Once you've done that you should end up with 2 DLL files in the same directory as the .ocx file. One called AxShockwaveFlashObjects.dll and another called ShockwaveFlashObjects.dll.
You don't care about ShockwaveFlashObjects.dll, just AxShockwaveFlashObjects.dll.
Grab that file and the Flash*.ocx file and paste them into the project directory.
Then include them into your references. This should open up two new references, AxShockwaveObjects and ShockwaveObjects.
Make sure you're Using both of them.
After this, you have to register the Flash*.ocx using RegSvr32 from your command prompt (make sure to run CMD in admin mode). That is done like so:
C:\RegSvr32 <path>\Flash.ocx
This worked for me. I was having the exact same problem (which is what led me here). It could be a half backed hack workaround but for now, that's how it worked for me.
Let me know if it works for you or not.
Hope it goes well for you.
I know this is an old post but I had this issue yesterday and the solution, at least in my case, was very simple. All I had to do was to change the Platform and Platform Target to x86 (Build tab of project property).
I know there is NSDesktopDirectory that will get me the path to current user desktop directory, but where is this path value written and is there a way to change it from my cocoa application I cannot find out.
Can anyone point me in the right direction?
Additional explanation: in Snow Leopard when I rename Desktop folder to anything whatsoever, the content of this folder still shows on desktop, so I guess OS keeps track about that folder name and locations changes and keep it as desktop folder. Does anyone know how it does that?
One way you could do this is by storing whole set of files from the user's desktop (including .DS_Store, which has positional/spatial information) into a folder in your ~/Library/Application Support/ folder, then moving other files on the ~/Desktop? This should effectively "replace" the user's desktop.
[Posted as an answer as suggested above]
I spent about 40 minutes researching this out of curiosity. Google is unhelpful in this particular scenario so I poked around my ~/Library folder. The path isn't stored anywhere there. I then dug around with command-line-fu to check flags and any other metadata I could find. Nothing helpful.
I think this is a built-in thing that uses file system references as opposed to hard-coded file paths (which is why its "Desktop" designation survives renaming). If you delete it, it creates a new one and stores the ref to that one. You'll not be able to swap it around.
I think Phil's comment is probably your best bet: move the contents of the folder rather than the folder itself. Here's my take on it:
~/Desktop/.myDesktop1 ... ~/Desktop/.myDesktop2 ... ~/Desktop/.myDesktop3
Perhaps even: ~/Desktop/.myappdesktops/1 ~/Desktop/.myappdesktops/2 ~/Desktop/.myappdesktops/3
If you move stuff into a dot-folder, it'll remain hidden but there. Active stuff stays in ~/Desktop as normal but each of your conceptual "Desktops" gets stored in a dot-file so it stays hidden.
Caveat: Time Machine. :-) Regardless of your approach, swapping out "sets" of files will potentially wreak havoc with any backup solution.
So, to answer my own question: there is no way to change the desktop path in Snow Leopard or Lion (although you van read it). The only way to switch dasktops is moving the contents itself which can be done with a set of AppleScripts to some degree :(.
The other way is this app here :)):
http://itunes.apple.com/us/app/projectdesktops/id499870251?ls=1&mt=12
I've always backed up all my source codes into .zip files and put it in my usb drive and uploaded to my server somewhere else in the world.. however I only do this once every two weeks, because my project is a little big.
Right now my project directories (I have a few of them) contains a hierarchy of c++ files in it, and interspersed with them are .o files which would make backing up take a while if not ignored.
What tools exist out there that will let me just back things up efficiently, conveniently and lets me specify which file types to back up (lots of .png, .jpg and some text types in there), and which directories to be ignored (esp. the build dirs)?
Or is there any ingenious methods out there that people use?
Though not a backup solution, a version control manager on a remote server responds to most of your needs:
only changes are saved, not the whole project
you can filter out what you don't want to save
Moreover, you can create archives of your repository for true backup purposes.
If you want to learn about version control, take a look at Eric Sink's weblog, in particular:
Source Control HOWTO, for the basics of source control
Mercurial, Subversion, and Wesley Snipes for the links to articles on distributed version control systems
I use dropbox, im a single developer developing software. In some projects I work out from my dropbox which means they synchronize every time i build. Other projects i copy the source code there my self. But most important is that i can work on all my computers with dropbox installed on them... works for my simple needs
Agree with mouviciel. If you do not want that, consider rsync or unison to efficiently keep an up-to-date copy, be it on the same or a different machine.