I'm trying to create a DLL using a Dataset.XSD file to access my website's VistaDB database. The DLL develops and builds fine but I need to build the DLL once and then change the "path" of the database in the all the Website projects that finally references the dll (different databases and therefor database paths for each website that references the dll in it's bin folder).
I can't get the ConfigurationManager.ConnectionString("myconstr").ConnectionString to stay in my DLL project. As soon as I save it - it reverts back to whatever the Dataset.XSD file wants it to be (the database connectionstring that I developed it against).
I figured out that if I just open it up in notepad, make the changes, and then build it works like it should. It's kind of a pain in the butt to do this every time I make a changes to the XSD file though but it's better than nothing, I guess.
Related
I am using vs 2015 update 3. In order to deploy my website, I create a web deploy package from the publish menu.
When I deploy that package, sometimes, some of the dll's are corrupted. When I ran the app I get an error that the dll is missing. When I open the dll with a disassembler, it is marked as an unmanged dll.
I can't find any difference between projects that work finק and the one's that don't, or between the dll that is fine and the one that is not.
I also tried deploying from VS Straight to my local IIS but that didn't help either.
What could this be?
After lots of debugging I found the problem.
In order to change variables in different environments we use parameters.xml file to set up the variables. There we had a settings to run on all js files and replace url's. The dll that was getting corrupted was newtonsoft.json.dll. since there is ".js" in the file name, the dll was beeing manipulated as well.
The solution was in the parameters.xml file to change the setting to be .js$. In that case it look for files that end with .js only and not all files.
I have an issue. We are upgrading to VS 2012 at work. When we open a VS 2010 project Visual Studio converts the project. This is fine, because VS 2010 can still use the project (yay microsoft). However, there is a \Backup folder created in the solution directory. Is this being created as part of the migration? Is there any way to control it?
The reason I ask is that the process that makes this folder copies web.config files into the folder. If you then try to build the solution (these are MVC projects), we get a "It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS." error. The cause is that there is a web.config file in a subfolder instead of the root folder. We did not make and do not want this change, and cannot figure out how to control it. Deleting the Backup\Web.config file fixes the error. Renaming it from web.config to web.config.bak fixes the problem.
I don't really want to have to personally open and convert every single project, and don't want random people bumping into this problem. Any idea how to either stop VS from creating the Backup folder, or how to make it create them in the my documents studio folder etc? I can't find any setting to control this and can't find any good info.
By chance, are you using the MvcBuildViews property to pre-compile your views at build time? If so, this is why you're encountering this (since it does the pre-compile in the same directory, it doesn't filter out any of the files below the project directory).
Note that you will also encounter this issue if you use the Publish feature for this project. Publish copies the web.config under your intermediate build output directory (by default, obj/) before and after applying web.config transforms.
The good news is that in VS2012, or in VS2010 with the latest Azure SDK installed, pre-compile is now supported for Web Application Projects (including MVC). These settings are currently in the project properties, under the Package/Publish Web tab.
(this doesn't directly address your question about the Backup folder, but it was too long for a comment.)
There is no way to control it that I found. We had to go ahead and run through and convert every project to 2012 and delete the backup folders to prevent any other team from running into it.
I have a web project which references a number of other projects, and when this web project is compiled, I'm getting the standard DLLs as expected for the project and others, but in addition there are 'duplicate' DLLs for all those projects with my computer name appended to the end:
MyServices.dll (and .pdb)
MyServices-computerName.dll (and .pdb)
When I run the website, I'm getting errors that the file could not be found, and that the DLL's manifest doesn't match the executable.
I tried cleaning the build, wiping everything and re-getting from source control, but they keep coming back.
If I manually delete them, the site runs fine, but they come back when I build.
this turned out to be a consequence of the source folder being synced with SkyDrive. During build, many changes are made to the dlls which essentially makes it look like multiple sources are updating the same files, so SkyDrive appends the computer name to the end of the files to preserve changes made from 'different' sources.
Skydrive application sync is creating multiple copies of files - Microsoft Community
This is a problem that has been eating at me for a while, and I just haven't found a good solution (no pun intended) for it.
I'm using Visual Studio 2010 with Subversion and Ankhsvn. It works very well, however, my biggest problem with it is that it only retrieves and manages files that are "included in the project". This is great in many situations, but kind of sucks when you want a folder with objects that you want to include in the solution, but do not want to have in the project itself (in this case a web project).
In this case, I want to include some 3rd party DLL's into source control (so they can be kept up to date when syncronizing with version control). I don't want the developers to have to install the 3rd party dll's seperately. What normally happens is that you reference the DLL's from some other location and they get copied into your bin folder at compile time.
I do not wish to include them in the project because i don't wan them copied to the web server when I publish the site (other than via the bin directory where they should be). I thought of creating a seperate project for these, but that would create a useless dll with no purpose that would then get copied to the bin folder because it's referenced.
I've also tried to check them in from the bin folder, but this has caused a number of problems where files did not syncronize prolerly, with subversion saying things about an already version folder being present etc.. This seems to be a subversion or ankhsvn problem rather than a visual studio one. As such, i try to keep the bin folder untouched by version control.
How have you solved this problem in your projects?
This is how we do it in our project.
We have a SourceCode folder which has the subfolders for the projects which contain the code.
Additionally this has a folder called Library which has the correct version of any 3rd party dll's that we use. This folder in in version control and hence everyone always has the correct version of the 3rd party dll's
All references in the projects to 3rd party dll's are relative from this Library folder.
Since everyone has the SourceCode folder on their machine, it works fine with no issues.
EDIT:
Added image of Solution Folder with library contents to it
(I know I am using Visual Source Safe, I do not have a choice because it comes with the MSDN Subscription license and my company does not want to buy a third party source control solution....)
I have a VS 2005 solution with 3 C# class library projects, 2 ASP.NET web site projects and one ASP.NET web service project that is stored in a Visual Source Safe database. Some of the projects reference a common library DLLs that handle common taskes.
When a new person sets ups the solution on their workstation and build it for the first time, it checks out the common library DLLs in the bin folder of the ASP.NET web site and web service projects. When another developer that is currently working on the project tries to build, they receive a "file excludely checked out by other user" message.
VS 2005 does not display the check mark next to the DLL that is causing the headache.
Is there a way to prevent this from happenning?
Why do you have the bin folder checked into SourceSafe? On projects I've worked on, the third party dlls were checked into a separate folder (maybe called ExternalLibraries or ThirdParty) at the same level as the solution file. The compile process would be set up to copy the dlls into the bin folder. This could be handled with .refresh files, or with a pre- or post-build step. This way, VisualStudio/SourceSafe won't see the files as having been updated, and won't try to check them out.
If the compile is already pulling the files in due to them being dependencies, I'd suggest removing the bin folder from VSS. This is not the same as an "Exclude folder from project" which hides the folder from VS05 when compiling (and gives you the compile error you mentioned.)
If the third party dlls aren't going to change, another option is to make those files read-only in VSS. This way, no users will be able to check out the files. (To mark the files read-only, you will need to change the permissions from the VSS management tool; the developer's tool doesn't have that feature.)
As for why it happens, I don't believe VSS checks the binary version numbers - it is only concerned with modify file date. If a new developer pulls all the code out, all files (including binaries) will have the current date as the modify date. This may be causing the unnecessary checkouts.
Regarding your later comments - I'm not sure why VS05 wouldn't see the files as under source control but the VSS UI does. I suspect it has to do with the .vss files (and similar) that are in that folder. In this case, VS05 is incorrect.
Not sure if this is the problem or the best fix, but if you update every developer's machine so that they have the same latest versions of the common DLLs installed, this shouldn't keep happening. I think VSS checks out the DLLs in the \bin folder if the version referenced by the project file doesn't match the version installed on the developer's machine.
#Pedro:
In the VS 2005 IDE inteface, it does not indicated that the \bin folder is in VSS. When I look at the project in the VSS UI, it shows that is checked out to the user who did the latest build on their workstation.
If I use the "Exclude folder from project" option, it will cause the compiler to throw "reference not found" errors.
In my solution structure, the class library project creates a reference to the third party DLLs using the "Add Reference" command. Then I set a project reference to the class librarys in my ASP,NET web site and web service projects (using the web site project template). Because the class library has a dependency on the third party DLLs, they are copyed in the \bin folder.
How do I set a file to read-only through the VSS UI?