I am curious about using an object db so thought i'd give Eloquera a go.
I am having problems getting it running unfortunately. (running in "desktop mode")
I have done these steps as directed:
1) Copy the following assemblies and a configuration file from the %ProgramFiles%\Eloquera folder into a project folder:
Eloquera.config
Eloquera.Client.dll
Eloquera.Common.dll
Eloquera.Server.exe
You can copy the reference files into a separate folder for your convenience.
2) Uninstall the Eloquera DB (sounds awful, but we have copies all files we will need) - (I never installed it)
3) Add Eloquera.config into your project via “Add an existing item…”, and set its "Copy to Output Directory" property to "Copy Always". Done
4) Add the project references to these files:
Eloquera.Client.dll yep
Eloquera.Server.exe yep
5) Rebuild your project and check that Debug\ and/or Release\ folders contain the following files along with your application:
Eloquera.config
Eloquera.Client.dll
Eloquera.Common.dll
Eloquera.Server.exe
It does
6) You may change a physical path to the database files in the Eloquera.config file by setting DatabasePath value:
DatabasePath="c:\dev\db" I did this also
The error i get is this:
The connection to the server (local) on the port 43962 cannot be established.
The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
Weirdly, changing ServerPort to something else in the config does not change this error.
Any ideas?
I think this mode is not supported.
You are meant to use Client / Server mode, which is a shame cause i was hoping i could use this desktop method to deploy into a shared host.
No dice.
You can download from Eloquera website desktop project that is already configured and working and can be used as a base.
Kohan,
Desktop mode is supported in Eloquera, otherwise my application would not work. :-) There is a good start-up project for the desktop application on the Eloquera web site, have a look at that.
I get this issue with VS2010 and 64 bit Windows 7 - if you are using the 32 bit dlls (as we are as our app needs to work on 32/64) then make sure your target build (in VS) is set to 32 bit rather than AnyCPU.
I still cannot get the Database browser working but the code is working now.
Also - obvious things like make sure your firewall is turned off etc. make sure you can telnet onto the port
Related
I am in an interesting situation where I maintain the code for a program that is used and distributed primarily by our sister company. We are ready to distribute the program to all of the 3rd party users and since it is technically our sister companies program, we want to host it on their website. (in the interest of anonimity, I'll use 'program' everywhere instead of the actual application name, and 'www.SisterCompany.com' instead of their actual URL.)
So I get everything ready to go, setup the Publish setting to check for updates at program start, the minimum required version, and I set the Insallation Folder URL and Update Location to "http://www.SisterCompany.com/apps/program/", with the actual Publishing Folder Location as "C:\LocalProjects\Program\Publish\". Everything else is pretty standard.
After publish, I confirm that everything installs and works correctly when running directly from the publish location on my C: drive. So I put everything on our FTP server, and the guy at our sister company pulls it down and places everything in the '/apps/program/' directory on their webserver.
This is where it goes bad. When I try to install it from their site, I get the - File, Program.exe.config, has a different computed hash than specified in manifest. Error. I tested it a bit, and I even get that error trying to install from any network location on our network other than my local C: drive.
After doing the initial publish in visual studio, I have changed no files (which is the answer/reason I've found by doing some searching about this error).
What could be causing this? Is it because I set the Installation Folder URL to a location that it isn't initially published too?
Let me know if any additional info is needed.
Thanks.
After bashing my head against this all weekend, I have finally found the answer. After unsigning the project and removing the hash on the offending file (an xml file), I got the program to install, but it was giving me 'Windows Side by Side' Errors. I drilled down into the App Cache were the file was, and instead of a config .xml file, it was one of the HTML files from the website the clickonce installer was hosted on. Turns out that the web server didn't seem to like serving up an .XML (or .mdb it turns out) file.
This MSDN article ended up giving me the final solution:
I had to make sure that the 'Use ".deploy" file extension' was selected so that the web server wouldn't mangle files with extensions it didn't like.
I couldn't figure out why that one file's hash would be different. Turns out it wasn't even the same file at all.
It is possible that one of the FTP transfers is happening in text mode, rather than binary?
For me the problem was that .config transformations were done after generating manifest.
To anyone else who's still having trouble, five years later:
The first problem was configuring the MIME type, which on nginx (/etc/nginx/mime.types) should look like this:
application/x-ms-manifest application
See Click Once Server and Client Configuration.
The weirder problem to me was that I was using git to handle the push to the server, i.e.
git remote add live ssh://user#mybox/path/to/publish
git commit -am "committing...";git push live master
Works great for most things, but it was probably being registered as a "change," which prevented the app from installing locally. Once I started using scp instead:
scp -r * user#mybox/path/to/dir/
It worked without a hitch.
It is unfortunate that there is not a lot of helpful information out there about this.
I got Team Explorer Everywhere so we can use TFS on the Mac Mini we got to test Iphone apps. Since we're using XCode for phonegap, we need to use the commandline program and it is giving me a lot of grief.
What I've done so far (Listing out for anyone who stumbles on this so they can use it):
-Downloaded the trial (free)
-Set the path using PATH=$PATH\:/FOLDERLOCATION
-Accepted EULA and got trial product key... for command line program (tf eula/tf productkey -trial)
-Set up workspace:
tf workspace -new WORKSPACENAME -server:http://SERVERNAME:PORT/FILEPATH -comment:"WORKSPACENAME" && prompted for username -> domain -> password
-Trying to setup the folder path (Fixed):
tf workfold -map SERVERFOLDERPATH LOCALFOLDERPATH -collection:http://SERVERNAME:PORT/FILEPATH -workspace:WORKSPACENAME && prompted for username -> domain -> password
-Make sure I can check out/check in (On hold):...
The error I'm getting right now is "An argument error occurred: First free argument must be a server path." This is what I've been following ever since I got the path set, but I think the versions are different because mine doesn't seem to be set up the same. Any help at all would be appreciated, and I'll keep up with the post as I figure parts out because there doesn't seem to be much online that I can find on TFS on macs.
Update: As normal, I'm an idiot. Have to put the options at the end of the command and have to have the serverfolder path as the first thing after -map. Now I just need to figure out how to use the damn thing. I'll post any other questions I have and try to get all the correct commands up for the selfish reason of having them somewhere in case I forget them later.
Update 2: The mapping hasn't worked out as well as I'd hoped, it seems a combination of my unfamiliarity with Unix/Mac file systems and some settings being missing is keeping me from using 'tf get' to load all of the test data I was trying to get. I'm planning on trying again after I get the location of where my boss wants the data saved and after I can look into something that would save the workspace so it won't say that it can't find the map path every time...
It looks like you're setting up your workspace and some working folder mappings just fine, after the edit. If you're having problems doing a tf get after this, then there are some common problems that might be occurring. TFS workspaces can be a little bit opaque and having a better understanding of them can sometimes help you understand where the problem is:
Team Foundation Server requires a workspace to be configured before you can get files out of source control, edit them or check them back in. A workspace basically simply contains working folder mappings that map your local path(s) to server path(s).
Workspaces are stored on the server and are uniquely identified by your computer's hostname, your username and the workspace's name. A cache of this information for the local host is saved on the client. This implies:
If you remove a workspace on the server, your workstation will be unable to connect.
If you remove the cache, your local computer will not be able to identify the workspace based on working folder mappings until the cache is rebuilt (which happens every time you connect to the server.)
If you change your username or local workstation's name, you cannot access those workspaces.
(Note that very early versions of the Teamprise command line client had certain issues on Mac OS that made identifying the local workstation name difficult. This is fixed, however, in Team Explorer Everywhere.)
Because you can have multiple workspaces for a single server on a single workstation, you can't always simply provide server paths to tf commands, since server paths are ambiguous. ($/ exists in every workspace, for example.) So the command line client resolves paths based on the current working directory and/or the arguments provided. Meaning that you can run tf get foo.txt if you're in a working folder, or you can run tf get /tmp/foo.txt if /tmp is mapped.
One more point - the configuration data for Team Explorer Everywhere is shared between the TFS plug-in for Eclipse and the command line client. So if you're more comfortable using a GUI to set up your workspace(s), you can do that and then use the CLC as you see fit. You don't need to be a Java programmer to use Eclipse - simply download Eclipse and install the TFS plug-in for Eclipse into it, and select Window > Open Perspective > Team Foundation Server Exploring. After that, you'll have the full GUI Team Explorer experience and this perspective will be restored when you open Eclipse, so you won't even need to worry about the Java IDE bits if you don't want to.
I have been trying to publish my service to windows azure. The service consists of a single webRole, however I have added remote login functionality published it and built it a few times, and now all the sudden it will not build. The reason it gives is that
Details below:
"Error 56 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets 202 5 FileSystemCreator"
I have gone on all the forums, I have used CSPack command line for packaging the service which is fine but I'm having a really hard time configuring the certificate for remote desktop connect and I would like to take advantage of this feature as I am creating some websites in the onStart event and I would like to peek into IIS. Some microsoft employees do agree that this is a bug and the have promised a fix this issue, refer to post . I am using VS2010 and I do not know how to fix this bug.
Can anyone please help, or point me to a place where I can get any help.
I ran into the same problem with a new solution.
Note that, unlike Eugenio Pace's response suggests, the error occurs only when deploying to Azure (and not when running the project in the Azure Compute Emulator).
Try adding the following line to the first property group of your Windows Azure Visual Studio Project file (*.ccproj):
<ServiceOutputDirectory>C:\Azure\</ServiceOutputDirectory>
The trailing slash (for whatever path you select) appears to be required. This folder will be deleted each time you create a package if it exists.
This setting seems to redirect the working folder for the package to a shorter base path, preventing the path too long error.
Credit goes to: http://govada.blogspot.com/2011/12/windows-azure-package-build-error.html
Perhaps the local folder used to store temporary development fabric is too long. See Windows Azure - Resolving "The Path is too long after being fully qualified" Error Message.
I was having this problem as well when deploying a Node.js project to Azure.
To fix it, I had to change my "TEMP" and "TMP" user environment variables to something shorter than their default values.
In my case, they were pointing by default to %USERPROFILE%\AppData\Local\Temp, changing them to C:\Temp solved it.
Make sure you restart Windows after.
The better solution may be to create a symbolic link to your project folder. This doesn't require moving files or changing system variables. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.
Same problem happened to me when I try Packaging an Umbraco project for Azure (https://github.com/WindowsAzure-Accelerators/wa-accelerator-umbraco/wiki/Deployment), I found the solution is to: Copy and rename the long-name path and folder to "C:\someshortname".
(solution was suggested by this: link)
I tried all the above 2 approaches:
-change TEMP and TMP enviromental variables
-<ServiceOutputDirectory> path
and didn't work.
In my case, I had to move the whole project to a shorter path C:\ and worked.
I'm using W7 and VS12.
When you run a cloud service on the development fabric, the development fabric uses a temporary folder to store a number of files including local storage locations, cached binaries, configuration, diagnostics information and cached compiled web site content.
By default this location is: C:\Users\\AppData\Local\dftmp
Credit goes to Jim Nakashima of Microsoft :
https://blogs.msdn.microsoft.com/jnak/2010/01/14/windows-azure-resolving-the-path-is-too-long-after-being-fully-qualified-error-message/
In order to change the temporary folder, a user environment variable has to be created :
It is named _CSRUN_STATE_DIRECTORY
Give it a value of short named directory like :
c:\AzureTemp
Don't forget to restart Visual Studio in order to have the environmennt variables to be read again
It fixed many compilations problem !
I have a simple Silverlight program that displays a bunch of images. I modified it do display more images, but it when I hit "run without debugging" is keeps running the old build with fewer images. When I copy the code into a new project and run it, it works fine for the first time, but then each subsequent change is not displayed. What could be the problem? I'm using Visual Web Developer 2008 Express.
Always check "Configuration Manager" option on "Build" menu in Microsoft Visual Web Developer. The checkBox "build" has to be checked, otherwise it won't build.
Happened to me, I hope this helps others.
I just had this happen to me in VS 2013 for Web. Had to change the Project URL in:
"Project properties"
"Web" tab
"Servers"
To a different localhost number and recreate Virtual directory.
Before my Project URL was:
http://localhost:55487/
I changed it to:
http://localhost:55488/
Then clicked "Create Virtual Directory".
Would like to know why this happened in the first place.
I found that I had to close all open instances of Visual Studio before I got it working again
This happens because your cache memory is full. just go to you bin and obj folder and delete all the temporary files. Now it will run properly.
Maybe it's a caching issue (webbrowser / proxy).
To fool the browser try to embed the xap file with an additional parameter that changes every time you open the plugin:
<param name="source" value="ClientBin/BubuApp.xap?<%=Guid.NewGuid().ToString() %>"/>
If this don't help, try to clean the project (delete obj / bin folders & xap file).
I was also suffering from this issue and none of the suggestions worked. I was building a Office.js add-in and debugging was with IIS Express.
What fixed the issue for me was deleting files in
C:\Users\<user>\AppData\Local\Temp\Temporary ASP.NET
Actually, I went ahead and and deleted the entire C:\Users\<user>\AppData\Local\Temp folder out of spite :)
I also had this issue and while some of the fixes above helped temporarily, the one that worked for me was to remove the history and caching in Internet Options.
Go into Internet Option (also available in VS via Tools > options > Environment > Web Browser > Internet Explorer Options).
On the General tab click Settings in the Browsing History section.
On the Temporary Internet Files page select Every time I start
Internet Explorer
On the History tab set the Days to keep history to 0
On the Caches and Database tab make sure Allow website caches and
databases is NOT ticked.
I'm not sure if all of the above are required, but I've made a number of changes to files and so far they have been reflected straight away in the dynamic versions without any noticeable performance problems.
I've also since realised if I set 'Every time I visit the webpage' instead of 'Every time I start Internet Explorer' I don't have to stop and restart the project to see the changes. Which is how it should be!
I used to suffer this. All of this used to be (for me) a folder's contents issue.
Maybe you can check this:
Delete %windir%\microsoft.net\framework\v4.0xxx\Temporary
IIS Express: even if you change the output file for compiled results, you will see in applicationhost.config that many times IISExpress is really "looking" to the default bin folder of your project.
It is even possible that you have different configurations for Debug or Release, so maybe IIS is looking BIN with Release code, and you are now compiling in Debug to another folder, do you understand me?
Happened to me too. Well i dont know the exact reason for this behavior. But when i close the visual C express 10 and then open again and build it builds the new saved file. I guess it still hangs on to the old file when there is an error in some debug mode or something.
Stop all incntance of VS.
Delete all /bin, not just /bin/Debug. All /bin
Remove user option .suo file in solution dir. It will create on self.
Remove all restore windows point
Stop IIS.
6 Start IIS after 1 minutes.
Rebuild solution, Buid projects
It happing on me too. Very nasty. You may restart your computer.
Check for global asembly dll.
Just delete folder 'Release' in project with old code build.
I had the same problem and none of the answers were working for me. It turns out that building the ASP.Net project did not build the Silverlight project, so running without debugging didn't update the Silverlight.
Fix: Right click the Asp.Net project. Build Dependencies > Project Dependencies. Check the Silverlight project. Now building should work.
If this is a web application, change the Project URL with a new port number.
Example :
Change from http://localhost:3688/
To http://localhost:36881/
To do this:
Navigate to Project properties -> Web
Change the URL
Hit "Create Virtual Directory"
Finally, Build and RUN
I had this issue in a web site.
The site referenced 1 of the projects in the solution, and changes to it would not reflect in the debug.
Issue was a third project was referencing an outdated dll of the same same referenced project.
I removed the project and all references in other projects and readded and re-referenced everything and it worked fine.
Check you haven't got two versions of whichever file you're updating (one for one group of users, one for a different group of users).
In my case(VS 2015) it was because of the missing dll in the .exe directory... I made a "clean solution", then additionally deleted all bin and obj folders' contents. Reason to do so was VS keeping to load old dll build. Solution was to select folder of the running debug config, i.e. everytime I rebuild project destination location with dll and a reference to it stays with warning mark for some time until intellitrace does its job. After doing the setup mentioned above, I still have to do a manual rebuild on a project that generates a dll into specified dir. Pressing F5 does nothing, I don't have time to find out why... Main thing is its working for me
I had this recently too and I didn't see the answer here. I was changing an MMI to get rid of redundant buttons, and they didn't go away.
Really old legacy code. To make it keep user settings - like language - someone had made it keep the Settings. I was not allowed to change this, they want it like that.
To get rid of the old settings and allow new ones:
open regedit
navigate to HKEY_CURRENT_USER - Software - MyProject - SubProject
here you see Recent File List and Settings.
Delete Settings completely - don't worry, it will make a new one.
Please check is there any old .tlb file present in someother folder. In my case i was using the .tlb file generated using .NET dll and then created the .tlb file using RegAsm. I tried to use the .tlb file in vb6 code, it still refers old code only. After a long search i found same .tlb file older version found in Visual Studio\VB98 folder. I removed it then it worked fine. This may not be relevent for this issue but could give you another way of thinking
There is a scroll bar at the top which has 3 options:
debug
release
configuration manager
Make sure release is selected.
I had to clear browsing data and it worked in my case
I have a solution in Visual Studio that is comprised of 5 projects. The projects build to assemblies (.dll). I have the output path of each project set to \my-web-server\wwwroot\bin, which works fine on one project. In the properties for all of my projects, I have the output path set to the same directory, but when I try building all but one of the projects, I get the error:
Unable to copy file "obj\Release\Index.dll" to "\my-web-server\wwwroot\bin\Index.dll". Access to the path '\my-web-server\wwwroot\bin\Index.dll' is denied.
I assume it could be an issue with permissions, because my organization keeps things locked down, but I have no control over granting permissions. Any help in the right direction is much appreciated.
It must've been something silly. I deleted the .dll manually, then rebuilt. Looks like everything's working normally. Thanks.
The solution for me was to delete everything in bin and obj folders in every project. Just ran this powershell script as described here.
I had the same issue. A copy of Visual Studio (devenv.exe) was still running invisible in the background keeping the particular dll locked.
Delete all DLLs from the bin folder and build the solution.
just had the same issue, built a new project/solution, got it all working and then added to TFS.
Unfortunately I did not clean the build before adding and this meant some files that should not have been under source control were and were then read only(not checked out).
Manually deleting the files before rebuilding fixed the issue.
Most likely a program is running using that library.
This happens to me when running something to debug, and I forget to close it (not attached to IDE debugger).
And since this looks like a website, it is potentially due to the website being hosted from the development build folder, and someone is accessing it.
Similar to what Aequitarum said, it's mostly likely a locked file because it's in use. Since you have multiple projects, you mostly likely have references between them. And since you have all the projects outputting to the same folder any of the referenced projects will most likely get copied more than once if you have those files set to be deployed in the child project. (In a C# web application, you can view the properties of the reference and look at the "Copy Local" property.) And if you have the MsBuild project set to use multiple processors for the build, two child projects are both trying to copy the file at approximately the same time and one is erring out.
It's a very unique situation, but it is possible.
Working solution
Just go to Task Manager and search Detail (if its Win10) and search with your application name (for easy search just look at your windows user id wise)
And right click shows properties. just give the permission like Administrator access.
That's all its working fine for me. ( I was struggling for 1 week and its killed more my time)
It looks like WSearch Service locks up the files and does not release them. I disabled the service on WINDOWS 10 and was able to rebuild the solution.