How can I manually add the SQLite Entity Framework 4.0 provider without using the installer setup so that the Visual Studio New EDMX wizard will be able to use it to create a new data model?
I'm not sure which provider you are using, but I am asuming you are using the System.Data.SQLite provider available from http://system.data.sqlite.org/
In order to use the Design Time support in Visual Studio, you must download the installer and install everything. This will setup the Design Time support and also install the System.Data.SQLite and System.Data.SQLite.Linq assemblies into your development machine's Global Assembly Cache.
For your application to access the SQLite database, you will need to add a reference to those two assemblies to your project.
To do this, right click on the project and select "Add Reference". If you ran the installer, the two assemblies will be in the list. If you can't find them, download the assembly files from the website, put them anywhere on your drive and reference them by selecting the file.
To distribute your application, you simply need to send along the assembly files. The easiest way to do this is to put the two dll files in the installation folder.
You can do this by right clicking on the reference in the visual studio Solution Explorer, and selecting Properties. Here, set Copy Local to True. Now when your application compiles, a copy of the SQlite assemblies will be put in your target directory.
If you are deploying the files manually, simply copy along the assembly files and keep them in the same folder as your executable. If you are using One-Click Deployment or any other kind of Deployment, make sure the assemblies are deployed together with your application.
Note that, as far as I know, the assembly version used by the Design Time support must be the same version as the one deployed by your application. So if you update the one, make sure you update the other as well.
Related
Currently through Azure Devops, I'm setting up a .Net Desktop type with pipe-line that includes assembly libraries. In my understanding this should've work if the scenario was TFS is on-premise and I can just install any 3rd party non-nuget libraries in that server and make the build work. Right now I was able to make this work by literally copying the .dlls but I felt its more of a hack than actually letting the build know that I'm referencing assembly / non-nuget package libraries.
I'm pretty sure i've missed something, is there a way to properly set this up?
Even though it's not a recommend way, but you could check in these libraries/dlls in source control. TFS could download them from server to your build agent and refer them.
First, make sure your local build is successful and if just the TFS build is failing then it is usually due to dll reference path issue. Make sure that the Dll is referenced as a relative path in the project file (.csproj).
To add a relative reference in a separate directory, such as C:\tfs_get\Sources\assembly\abc.dll, do the following:
Add the reference in Visual Studio by right clicking the project in Solution Explorer and selecting Add Reference.
Find the *.csproj where this reference exist and open it in a text editor. Lets say your .csproj location is c:\tfs_get\sources\myfolder\myproject\myproj.csproj
Edit the < HintPath > to be equal to
..\\..\assembly\abc.dll
This build will work properly with the assumption that the folders ( assembly, myfolder) under the sources folder exist in TFS.
Update
Have a folder named "libs", or "libraries", for example, that contains all the assemblies required by your projects to compile and run.
Reference these assembly by right click the reference folder of project and browser to these assemblies files.
For build, in Source Settings (XAML, Build Agent Folder)/Repository, keep the similar structure.
More details please take a look at this similar question : How to properly check in DLLs/assemblies to TFS/Visual Studio Team Services (was VSO)
I create a new custom project type using a VSPackage project inheriting of MPF library (http://mpfproj11.codeplex.com/). As a result I obtain a .vsix but I need add this project type using a .msi. I'm using the Visual Studio 2010 Setup projet for it. In my setup project I add the content of the VS Package in the same directory where the .vsix put then, but I think Ineed to put in the registre the new type of project because when I use the setup , the project template does not come out in Visual Studio and when I give double click the file with extension of the type of new project and does not recognize it. When I look the registry after install the vsix, this was one of the things that I found diferent. I add this entries in my setup project but It's not working yet.I'm missing something else?
In the projecttemplatedir is the directory where I put the .dll of the project type, the vsixmifest and pkgdef. The project template is in [User]\Documents\Visual Studio 2013\Templates\ProjectTemplates\[Name of new Project Type]\[projecttemplate.zip]
Best Regards
PS: The project type is for VS 2013 but I'm using the VS 2010 Setup project ;)
OK, so first the "don't"s of doing this:
In general, if you are installing via MSI you shouldn't be doing anything user-specific -- no writing in HKEY_CURRENT_USER, nor writing within their Documents folder, LocalAppData, or Visual Studio folders, etc. If you see yourself writing files or registry keys in either of those places, that should be your hint that there's a better way to do what you're trying to do. For what you've shown so far, this raises more than a few red flags for me.
Second, don't ever go writing keys into 12.0_Config. That part of the hive is nothing more than a cache that's built up from other parts of the registry and on-disk .pkgdef files from extensions. It's rebuilt in any number of senarios, including installing new extensions. Any writes there you should presume will get blown away at any time. If you need to write things there you should either (a) write in HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\[version] and run devenv /setup or (2) [preferred] put your keys in a .pkgdef inside your extension which gets merged into 12.0_Config for you automatically.
Now the dos:
You said you already had a .vsix produced by the SDK: you can put project templates in there. You can then register those templates in the .vsixmanifest and those will pull in. That's far easier than mucking around with files in Documents -- that's the user's directory...don't go playing with that.
Once you have a .vsix that does most of what you need, you should simply take the files within that and install the files in a folder within C:\Program Files [(x86)]\Microsoft Visual Studio 12.0\Common7\IDE\Extensions. Even better, you might just want to WiX toolset to build your installer, since it has built-in support for installing extensions. It also has built-in support for invoking the "/setup" process if that's what you need to do as well. Visual Studio Setup projects are no longer supported in newer versions of Visual Studio, so you're better off starting with a technology that isn't already obsolete. WiX is even what we use at Microsoft to do the setup work for Visual Studio itself, so it's definitely up to the task.
Last point: almost everything when it comes to Visual Studio extensibility can be done with a VSIX directly, so presume there's a good way to do something that way before falling back to an MSI. Internally, we can register the entire C# and VB language services with just a VSIX -- they're quite powerful.
I found the answer in this link Registering Project and Item Templates. I set projecttemplatedir entry with
[User]\Documents\Visual Studio 2013\Templates\ProjectTemplates[Name of new Project Type][projecttemplate.zip] that is where i put the project template.
I have an update to third party .DLL that must be installed onto my clients' computers. We currently employ automated installs via MSI that are created in Visual Studio 2010
Unfortunately, the third party .DLL was versioned incorrectly and file version of it was not increased by the provider (they only increased assembly version). The third party provider is Microsoft, so waiting on them to fix the issue is not realistic. We need to get the new .DLL to people now and within one MSI update. Right now, MSI update is not overriding the .DLL
Is there a way within VS2010 Setup project to force override a .DLL even if the file versions match?
If you are willing to do msi postbuild tweaking you can hit the File table and do "version lying". Another thought is to not put that DLL in your install. Find an installer from Microsoft ( if it exists ) that you can put into a bootstrapper or create your own installer and use AMUS instead of OMUS for the version rules.
Can't you just add the file to your installer as a 'file' and install it with the other files? Don't set it as project output, or any of the canned install actions. Go to the file portion and right click the "Application Files" folder, and say > add file. Navigate to the file that you want and choose it.
I have several Visual Studio web application projects that include SVN externals. When a new file is added to an external module, VisualSVN brings it down to the file system, but doesn't add it to the Visual Studio project; it has to be manually added.
I might write a macro to automate this process, and I'm wondering if I can make it a one-step process by either:
Having the macro initiate the VisualSVN update, then do the work (Q: Is it possible to trigger a VisualSVN update from a macro?)
Hooking into a hypothetical "post-update" event from VisualSVN to fire a macro to do the work (Q: Does such an event exist?)
I assume you are currently working like this: your "external modules" are just a loose collection of source files without a project file. Whenever a source file is added, you update all your application project files by adding the new source file, so that it is compiled into all the application assemblies.
I think you are doing it wrong. Your project solution file should contain a reference to a separate visual studio project file for each external. Each source file should be compiled into exactly one assembly.
For example, you might have a C# library shared between multiple web applications. This library has its own .csproj project file, which lives in the external location. If a source file is added to the library, the .csproj is updated. The updated .csproj file is then pulled it via an svn:externals declaration when you update your project.
(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?